[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 2 Sep 2012 11:19:18 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Best bikeshed ever (feature test macros)
On Sun, Sep 02, 2012 at 10:48:13AM +0200, Arvid E. Picciani wrote:
> Heya,
>
> i'm a bit confused over 1 vs 2.
With option 1 (leaving things as-is), invoking the compiler with no
feature test macros gives the same effect as invoking "gcc -std=c99"
on glibc: only stuff from plain C is visible. It's pretty much
impossible to find or write software where this mode has any practical
value, so the only values of option 1 are:
- The ideological purity of providing a straight conforming C
environment by default
- Breaking "bad software" that's failing to use feature test macros to
request the functionality it needs.
It's the latter of these two points that seems to be the point of
interest and controversy.
On the one hand, there's the argument that programs that want to use
whatever extension features the system offers cannot portably request
this; there are systems where ANY use of feature test macros removes
some extensions that are visible by default, and provides no way to
get them back.
On the other hand, relying on the default environment to be sane is
fundamentally broken. For example, glibc by default gives you an
incorrect version of strerror_r that doesn't even have the right
prototype, and misbehaving versions of basename, scanf, and other
functions. I'm pretty sure that at one point, certain proprietary
unices like Solaris were even worse, providing horribly non-conforming
legacy environments with bug-compatibility for legacy versions unless
you used the right feature test macros. No idea if they've all been
fixed or if they're even still relevant.
At this point it sounds like programs that are omitting all feature
test macros by default are hopelessly broken and not even worth trying
to support. However, the fact of the matter is that they "work" on a
large portion of systems, and on systems where the above issues are
show-stoppers, you can _add_ some feature test macros (rather than
having to remove them) to get the app to work. Right now, we're in the
situation where musl is one of the systems where such apps don't work,
and the issue can be solved by adding -D_GNU_SOURCE (or often just a
POSIX/XSI feature).
The question is whether it would be more valuable to change things so
that musl is a system where the default environment is "just working"
even better than glibc's (by virtue of exposing all the useful
extensions but not doing broken things like exposing the wrong
versions of strerror_r, basename, etc.).
> On Fri, 24 Aug 2012 17:41:38 -0400, Rich Felker wrote:
>
> >Using -D_GNU_SOURCE works 99%
> >of the time, but the other 1% of the time it will _break_ programs
> >that are already correctly using -D_XOPEN_SOURCE=700
> >
> >2. Making the kitchen sink (_GNU_SOURCE) available by default.
> >
> >PROS: Works with most software and won't break software that's
> >already
> >correctly using feature test macros.
>
> I see how _GNU_SOURCE breaks stuff, but how does it not break if its
> the default?
If software is already correctly using feature test macros, it's
getting an environment it selected, not the default environment, so
changing the default will have no effect on such software.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
