Re: Re: Best bikeshed ever (feature test macros)

[Rich Felker <dalias@aerifal.cx>]

On Wed, Aug 29, 2012 at 10:08:34AM -0500, Bobby Bingham wrote:
> On Wed, Aug 29, 2012 at 9:43 AM, Rich Felker <dalias@aerifal.cx> wrote:
> >
> > 3. Make as much software as possible "just work".
> >
> 
> I would much rather that the software worked because it was correct,
> and not because musl worked around its brokenness.
> 
> I realize this isn't a very practical viewpoint, especially if you
> hope to have musl see any adoption, but you asked for opinions and I
> think broken software should be allowed to break.  The fixes belong in
> those projects, not worked around in musl.  This is wishful thinking,
> but perhaps if we had a major libc that exposed this brokenness by
> default, it would raise awareness among the authors of other software
> and they would fix it.

Unfortunately a large portion of projects that need extension
functionality of any sort are unwilling to "fix" the issue, because
the existing libcs are so broken. For example, if you want the kitchen
sink on some (most?) BSDs, the only way to get it is to omit all
feature test macros entirely. This makes project maintainers very wary
of using feature test macros.

In principle, musl's approach changed from "make sure broken programs
break as often as possible" to "be as compatible as possible within
the letter of the specs" a long time ago. For example with expose
MAP_ANONYMOUS by default even though it's officially an extension,
because MAP_* is in the reserved namespace for mman.h, making it legal
(albeit of course not required) to expose it. There are several other
places where we do the same with nonstandard fields in structures; if
the field prefix (e.g. st_*, etc.) is in the reserved namespace, we
take advantage of that to accommodate applications as much as
possible.

I originally wanted to pressure broken programs to fix their breakage.
But the goal of musl is to fix libc, not to fix every broken program
out there. And I don't think we can do both at the same time...

> With glibc providing the kitchen sink, they have very little incentive
> to do anything about it, if they're even aware of it in the first
> place.

Actually glibc does something more like #3, but worse. By default it
only standard C functions and unixy stuff that was in _legacy_ unix.
And maybe some random subset of newer stuff they like. It's a very
ugly situation to be dealing with, much uglier than "the kitchen sink"
since some important, desirable interfaces are missing.

> I vote for #1.

Noted. :-)

Rich