Best bikeshed ever (feature test macros)

Best bikeshed ever (feature test macros)

[Rich Felker]

Hi all,

Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -D_GNU_SOURCE,
etc. things everybody gets wrong) have been one of the more
controversial aspects of musl, particularly the fact that musl
presents by default a straight ISO C conforming environment with no
POSIX, traditional Unix, etc. stuff offending the pristine C
namespace, and requires the use of one or more feature test macros to
get basically _ANY_ typical unixy software to build.

There's been some (mostly dead-end) discussion over the past few weeks
from folks who are unhappy with this situation or want it to change; I
suspect there are also some purists who want every application out
there to change and make explicit what features it depends on.

In this thread I'd like to gauge opinions on the matter. In other
words, this is the ultimate bikeshed thread.

To give it some direction, I'd like to start off with some pros and
cons of the different options...


1. Leaving everything as it is.

PROS: Obtaining conforming standard C environment is easy. Detecting
(for the purpose of flaming or fixing) programs failing to use feature
test macros correctly is also easy.

CONS: Basically every program requires a feature test macro to be
added to CFLAGS in order to compile it. 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 or similar by
introducing nonstandard functions that pollute the namespace and
conflict with the application. Thus it becomes really hard to have a
universal working build procedure. It's also very hard to work around
broken build systems (like GCC's bootstrapping) that refuse to honor
your custom CFLAGS.


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.

CONS: The preprocessor logic in the headers becomes MUCH uglier. And
purists may object to this on moral grounds.


3. Making only some limited subset (e.g. POSIX base) available by
default.

PROS: Easy to do, e.g. by adding "|| !defined(__STRICT_ANSI__)" to all
POSIX functionality #ifs. Cannot break any correct code in the default
configuration except pure ISO C code that's non-POSIX, and even then,
-std=c99 fixes it. Might cause applications to be built with less GNU
interface dependencies.

CONS: Probably fails to get a significant portion of apps working.


Much like the last thread I created to assess opinion (the license
one), this is all fairly open-ended and not necessarily going to lead
to any short- or long-term change in direction, but then again it
could... Replies don't have to be of the form 1/2/3; alternative ideas
are welcome, as are replies that just address which goals/criteria are
most important to you.

Rich

Re: Best bikeshed ever (feature test macros)

[Gregor Richards]

On 08/24/2012 05:41 PM, Rich Felker wrote:
> Hi all,
>
> Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -D_GNU_SOURCE,
> etc. things everybody gets wrong) have been one of the more
> controversial aspects of musl, particularly the fact that musl
> presents by default a straight ISO C conforming environment with no
> POSIX, traditional Unix, etc. stuff offending the pristine C
> namespace, and requires the use of one or more feature test macros to
> get basically _ANY_ typical unixy software to build.
>
> There's been some (mostly dead-end) discussion over the past few weeks
> from folks who are unhappy with this situation or want it to change; I
> suspect there are also some purists who want every application out
> there to change and make explicit what features it depends on.
>
> In this thread I'd like to gauge opinions on the matter. In other
> words, this is the ultimate bikeshed thread.
>
> To give it some direction, I'd like to start off with some pros and
> cons of the different options...
>
>
> 1. Leaving everything as it is.
>
> PROS: Obtaining conforming standard C environment is easy. Detecting
> (for the purpose of flaming or fixing) programs failing to use feature
> test macros correctly is also easy.
>
> CONS: Basically every program requires a feature test macro to be
> added to CFLAGS in order to compile it. 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 or similar by
> introducing nonstandard functions that pollute the namespace and
> conflict with the application. Thus it becomes really hard to have a
> universal working build procedure. It's also very hard to work around
> broken build systems (like GCC's bootstrapping) that refuse to honor
> your custom CFLAGS.
>
>
> 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.
>
> CONS: The preprocessor logic in the headers becomes MUCH uglier. And
> purists may object to this on moral grounds.
>
>
> 3. Making only some limited subset (e.g. POSIX base) available by
> default.
>
> PROS: Easy to do, e.g. by adding "|| !defined(__STRICT_ANSI__)" to all
> POSIX functionality #ifs. Cannot break any correct code in the default
> configuration except pure ISO C code that's non-POSIX, and even then,
> -std=c99 fixes it. Might cause applications to be built with less GNU
> interface dependencies.
>
> CONS: Probably fails to get a significant portion of apps working.
>
>
> Much like the last thread I created to assess opinion (the license
> one), this is all fairly open-ended and not necessarily going to lead
> to any short- or long-term change in direction, but then again it
> could... Replies don't have to be of the form 1/2/3; alternative ideas
> are welcome, as are replies that just address which goals/criteria are
> most important to you.
>
> Rich

My vote is for something like (3). My “ideal” would be an imaginary 
macro that's “every symbol ever exposed by POSIX+X/Open, plus some 
specific version of BSD”, so it's POSIX.2008 plus everything removed 
from POSIX.2001 etc and some very classical set of BSD extensions. If 
there were a _BSD_SOURCE=<some reasonable version of BSD>, so that 
_BSD_SOURCE actually meant something, I would want that, but since 
there's not that's a bit grotty. _XOPEN_SOURCE=700 does actually cover 
most things, and I think many programs would work with it. 
_XOPEN_SOURCE=700|_BSD_SOURCE is /very/ close to what every other libc 
will give you.

I strongly object to (2), as even glibc does not expose GNU extensions 
by default. Plenty of libcs expose everything by default, but we should 
not strive to be even worse than glibc…

I actually don't have a problem with (1) in theory, but in practice it's 
a pain, because you wind up in situations where it is impossible to 
write a program which correctly compiles on both musl and [name random 
other libc]. This makes musl a nightmare to port to, and for such an 
absurd reason. Here's why, in examples:

glibc: Default is not _GNU_SOURCE, contrary to popular misconception. 
The default is _BSD_SOURCE|_SVID_SOURCE|_POSIX_C_SOURCE=200809L . 
_BSD_SOURCE|_SVID_SOURCE covers most of the things in _XOPEN_SOURCE too, 
so you can effectively think of it as something similar to 
_BSD_SOURCE|_XOPEN_SOURCE=700. If you set anything or use -std=c*, you 
lose everything; but if you want everything back, it's just a 
_GNU_SOURCE away.

BSDs: Default is (approximately) everything. Again, if you specify 
-std=c* OR any feature test macros, you lose BSD functions (and some 
POSIX.2008 functions where it's not up to date). In the case of FreeBSD, 
you /cannot get them back/ without poking at internal defines that 
you're not supposed to touch. Other BSDs support _BSD_SOURCE, but 
FreeBSD does not. This means that if your BSD is out of date, as they 
all are, and you specify a POSIX version that includes things it has 
under _BSD_SOURCE, you're just plain screwed. So, to make things work on 
BSD, the safest thing to do is define nothing. Except that then it won't 
compile on musl. FreeBSD and other BSDs provide /broken functions/ if 
you specify _GNU_SOURCE, bug compatible with long-since fixed bugs, so 
it is almost always a bad idea to do so.

Solaris: Default is everything. Otherwise, this libc is a nightmare. The 
-std=c* version has to correspond to the _POSIX_C_SOURCE or 
_XOPEN_SOURCE version (even so far as you cannot use -std=c99 with 
_POSIX_C_SOURCE=199506L), which means that code which is properly 
labeled but happens to have been compiled on a new enough compiler will 
break for no reason at all. Further, like FreeBSD, if you specify 
anything, you lose everything, and to get it back you set 
__EXTENSIONS__, which is arbitrary and just yet another “everything” 
macro. It does not recognize _BSD_SOURCE, _SVID_SOURCE, _GNU_SOURCE or 
any other non-standard macros, so the only way to get everything safely 
is to specify nothing. Oh, and here's a nice trick: It's not up to date 
with _XOPEN_SOURCE=700 yet, and if you set _XOPEN_SOURCE=700, IT DOESN'T 
RECOGNIZE IT. It doesn't check >= 600, it checks == 600. Yeesh.

musl: Default is standard C only. There is /no way/ to get everything, 
except insofar as _GNU_SOURCE|_BSD_SOURCE happens to cover everything, 
until you find something that it doesn't. -std=c* have no effect. Code 
that is properly labeled works perfectly.


So here's the issue. If I have a program that is strictly POSIX version 
whatever, then I can safely set _POSIX_C_SOURCE=whatever and it will do 
the right thing everywhere (leaving out Solaris's stupid -std=c* 
nonsense). If I use ANY extensions, I'm screwed. Consider Microcosm, 
where in one part of the source I generate bindings to the native 
structures by scraping them from the headers with a generator program. 
Naturally, since I'm actually generating system-specific bindings here, 
I want /everything/. Before I ported Microcosm to be hostable on musl, I 
simply didn't set any feature macros, and all was well; EVERY other libc 
gave me everything I wanted.

Then I ported it to musl, and then I got it to work everywhere else 
again. Its feature macros look like this now:

#define _POSIX_C_SOURCE 200809L
#define _XOPEN_SOURCE 600 /* do not set to 700: Solaris is awful */
#define _GNU_SOURCE
#define _BSD_SOURCE
#define __EXTENSIONS__ 1
#define __BSD_VISIBLE 1

Note how I essentially have one line per libc. I had to change the 
feature macros every time I ported, THEN I had to go back and change 
them again. That's stupid. That's beyond stupid.

Feature macros are nice in theory, but in practice they're implemented 
too inconsistently. They're designed to make your programs more 
portable, but in reality, other than _POSIX_C_SOURCE, they only serve to 
make your programs less portable. It's unfortunate that this is a “you 
have to do it this way because otherwise reality will boot you in the 
face” situation, but you have to do it this way. Otherwise, reality will 
boot you in the face.

With valediction,
  - Gregor Richards

Re: Best bikeshed ever (feature test macros)

[Szabolcs Nagy]

* Rich Felker <dalias@aerifal.cx> [2012-08-24 17:41:38 -0400]:
> 1. Leaving everything as it is.
> 
> 2. Making the kitchen sink (_GNU_SOURCE) available by default.
> 
> 3. Making only some limited subset (e.g. POSIX base) available by
> default.
> 

i havent built many tools with musl yet so
i don't know the extent of the practical
issues

but i generally like the current approach

the only problem i see is that there are too
many feature test macros so the headers are
harder to maintain

Re: Best bikeshed ever (feature test macros)

[orc]

On Fri, 24 Aug 2012 17:41:38 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> Hi all,
> 
> Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -D_GNU_SOURCE,
> etc. things everybody gets wrong) have been one of the more
> controversial aspects of musl, particularly the fact that musl
> presents by default a straight ISO C conforming environment with no
> POSIX, traditional Unix, etc. stuff offending the pristine C
> namespace, and requires the use of one or more feature test macros to
> get basically _ANY_ typical unixy software to build.
> 
> There's been some (mostly dead-end) discussion over the past few weeks
> from folks who are unhappy with this situation or want it to change; I
> suspect there are also some purists who want every application out
> there to change and make explicit what features it depends on.
> 
> In this thread I'd like to gauge opinions on the matter. In other
> words, this is the ultimate bikeshed thread.
> 
> To give it some direction, I'd like to start off with some pros and
> cons of the different options...
> 
> 
> 1. Leaving everything as it is.
> 
> PROS: Obtaining conforming standard C environment is easy. Detecting
> (for the purpose of flaming or fixing) programs failing to use feature
> test macros correctly is also easy.
> 
> CONS: Basically every program requires a feature test macro to be
> added to CFLAGS in order to compile it. 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 or similar by
> introducing nonstandard functions that pollute the namespace and
> conflict with the application. Thus it becomes really hard to have a
> universal working build procedure. It's also very hard to work around
> broken build systems (like GCC's bootstrapping) that refuse to honor
> your custom CFLAGS.
> 
> 
> 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.
> 
> CONS: The preprocessor logic in the headers becomes MUCH uglier. And
> purists may object to this on moral grounds.
> 
> 
> 3. Making only some limited subset (e.g. POSIX base) available by
> default.
> 
> PROS: Easy to do, e.g. by adding "|| !defined(__STRICT_ANSI__)" to all
> POSIX functionality #ifs. Cannot break any correct code in the default
> configuration except pure ISO C code that's non-POSIX, and even then,
> -std=c99 fixes it. Might cause applications to be built with less GNU
> interface dependencies.
> 
> CONS: Probably fails to get a significant portion of apps working.
> 
> 
> Much like the last thread I created to assess opinion (the license
> one), this is all fairly open-ended and not necessarily going to lead
> to any short- or long-term change in direction, but then again it
> could... Replies don't have to be of the form 1/2/3; alternative ideas
> are welcome, as are replies that just address which goals/criteria are
> most important to you.
> 
> Rich

Will exposing everything by default enlarge program size by including
unneeded symbols?
From my point of view, appending -D_GNU_SOURCE everytime when you
install software on system is painful, but it can be "hidden", for
example, by adding CFLAGS/CXXFLAGS environment variable to your
~/.${SHELL}rc (but this still will be broken if you will need to append
CFLAGS again, you'll need to remember that CFLAGS are already set).

Re: Best bikeshed ever (feature test macros)

[Rich Felker]

On Sat, Aug 25, 2012 at 03:35:56PM +0800, orc wrote:
> Will exposing everything by default enlarge program size by including
> unneeded symbols?

The only way this could happen is if the newly exposed portions of the
headers include static inline functions and the compiler decides to
generate code for them even when they're not used.

The compiler could also increase the size of _debugging_ tables in the
output to include the unused types, etc. but not the size of actual
code.

> From my point of view, appending -D_GNU_SOURCE everytime when you
> install software on system is painful, but it can be "hidden", for

Actually it can't; this is the main problem with the current approach.
Unconditionally adding -D_GNU_SOURCE to CFLAGS for all programs
"fixes" most programs that should be using it themselves, but breaks a
small but nonzero number of fully-correct programs that are using
feature test macros properly to _avoid_ having their namespace
polluted by nonstandard symbols that conflict with their own use of
the corresponding names.

Thus, before you have build a package, you have to know whether it
makes use of feature test macros on its own.

Rich

Re: Best bikeshed ever (feature test macros)

[orc]

On Sat, 25 Aug 2012 08:32:15 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> On Sat, Aug 25, 2012 at 03:35:56PM +0800, orc wrote:
> > Will exposing everything by default enlarge program size by
> > including unneeded symbols?
> 
> The only way this could happen is if the newly exposed portions of the
> headers include static inline functions and the compiler decides to
> generate code for them even when they're not used.
> 
> The compiler could also increase the size of _debugging_ tables in the
> output to include the unused types, etc. but not the size of actual
> code.
> 
> > From my point of view, appending -D_GNU_SOURCE everytime when you
> > install software on system is painful, but it can be "hidden", for
> 
> Actually it can't; this is the main problem with the current approach.
> Unconditionally adding -D_GNU_SOURCE to CFLAGS for all programs
> "fixes" most programs that should be using it themselves, but breaks a
> small but nonzero number of fully-correct programs that are using
> feature test macros properly to _avoid_ having their namespace
> polluted by nonstandard symbols that conflict with their own use of
> the corresponding names.
> 
> Thus, before you have build a package, you have to know whether it
> makes use of feature test macros on its own.

Then I would recommend the #2 way or even to expose everything by
default since there is big number of software with their own
incompatible build systems, broken build systems like you said about
gcc, but there is still problem with ugly ones which logic uses
__GNUC__ and similiar macros (but we can omit them now just because
they are broken).
(Btw how uglier preprocessor logic will become?)

> 
> Rich

Re: Best bikeshed ever (feature test macros)

[Luca Barbato]

On 8/24/12 11:41 PM, Rich Felker wrote:
> Hi all,

> 1. Leaving everything as it is.
>
> PROS: Obtaining conforming standard C environment is easy. Detecting
> (for the purpose of flaming or fixing) programs failing to use feature
> test macros correctly is also easy.
>
> CONS: Basically every program requires a feature test macro to be
> added to CFLAGS in order to compile it. 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 or similar by
> introducing nonstandard functions that pollute the namespace and
> conflict with the application. Thus it becomes really hard to have a
> universal working build procedure. It's also very hard to work around
> broken build systems (like GCC's bootstrapping) that refuse to honor
> your custom CFLAGS.

Would be nice to see which would require something more first. The 
current musl seems working decently as-is.

lu

Re: Best bikeshed ever (feature test macros)

[Isaac Dunham]

On Fri, 24 Aug 2012 17:41:38 -0400
Rich Felker <dalias@aerifal.cx> wrote:

> Hi all,
> 
> Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -D_GNU_SOURCE,
> etc. things everybody gets wrong) have been one of the more
> controversial aspects of musl, particularly the fact that musl
> presents by default a straight ISO C conforming environment with no
> POSIX, traditional Unix, etc. stuff offending the pristine C
> namespace, and requires the use of one or more feature test macros to
> get basically _ANY_ typical unixy software to build.

I have built a few programs without extra CFLAGS.
(two of them being nebula & cmix)
> 
> 1. Leaving everything as it is.
> 

> 
> 2. Making the kitchen sink (_GNU_SOURCE) available by default.

This can be done the same way as 3, but it does mean a lot of extra
verbiage in the headers. 
Name collisions are something I've run into, though they're fairly
trivial to fix in my experience.
All told, I'd say it's practical but maybe not desirable.
And if you *are* going to make everything available, also make the
strl* functions and fgetln available, so software doesn't pull in its
own version due to broken tests (haven't noticed this happening,
but...).

> 3. Making only some limited subset (e.g. POSIX base) available by
> default.

I'd prefer some variant of 3. And the _XOPEN_SOURCE=600 || _BSD_SOURCE
suggestion does sound fairly reasonable except for some headers, like
<math.h>

Isaac Dunham

Re: Best bikeshed ever (feature test macros)

[philomath]

On Fri, 24 Aug 2012 17:41:38 -0400
Rich Felker <dalias@aerifal.cx> wrote:


> 1. Leaving everything as it is.

> 2. Making the kitchen sink (_GNU_SOURCE) available by default.

> 3. Making only some limited subset (e.g. POSIX base) available by
> default.

The bikeshed should definitely not be colored black.

I'd lean towards 3, 1 is fine too.  but please not 2, musl's correctness is one
of it's unique features...

Thanks.

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

[Rich Felker]

On Wed, Aug 29, 2012 at 07:34:42AM +0200, philomath wrote:
> On Fri, 24 Aug 2012 17:41:38 -0400
> Rich Felker <dalias@aerifal.cx> wrote:
> 
> 
> > 1. Leaving everything as it is.
> 
> > 2. Making the kitchen sink (_GNU_SOURCE) available by default.
> 
> > 3. Making only some limited subset (e.g. POSIX base) available by
> > default.
> 
> The bikeshed should definitely not be colored black.
> 
> I'd lean towards 3, 1 is fine too. but please not 2, musl's
> correctness is one of it's unique features...
> 
> Thanks.

Thanks for the input. What correctness aspect is important to you? I
conceptually like the minimal-by-default namespace, but ISO C does not
specify how to invoke the compiler, so even implementations that
require you to use obscure options to get a clean plain-C namespace
are "correct". In practice, any of the options 1-3 would give the
clean namespace as long as -std=c* is used with no feature test
macros.

With that said, I do tend to agree that option 2 is ugly, mainly since
it exposes not just useful modern extensions but all kinds of ugly
legacy things, like sys/sysmacros.h junk getting pulled in from
standard headers... So far the most reasonable proposals I've seen are
along the lines of "XSI plus some extensions" where the latter would
correspond to _BSD_SOURCE or some analogue of _SVID_SOURCE (which is
not supported by musl at this time).

Rich

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

[Gregor Richards]

On 08/29/2012 09:49 AM, Rich Felker wrote:
> On Wed, Aug 29, 2012 at 07:34:42AM +0200, philomath wrote:
>> On Fri, 24 Aug 2012 17:41:38 -0400
>> Rich Felker <dalias@aerifal.cx> wrote:
>>
>>
>>> 1. Leaving everything as it is.
>>> 2. Making the kitchen sink (_GNU_SOURCE) available by default.
>>> 3. Making only some limited subset (e.g. POSIX base) available by
>>> default.
>> The bikeshed should definitely not be colored black.
>>
>> I'd lean towards 3, 1 is fine too. but please not 2, musl's
>> correctness is one of it's unique features...
>>
>> Thanks.
> Thanks for the input. What correctness aspect is important to you? I
> conceptually like the minimal-by-default namespace, but ISO C does not
> specify how to invoke the compiler, so even implementations that
> require you to use obscure options to get a clean plain-C namespace
> are "correct". In practice, any of the options 1-3 would give the
> clean namespace as long as -std=c* is used with no feature test
> macros.
>
> With that said, I do tend to agree that option 2 is ugly, mainly since
> it exposes not just useful modern extensions but all kinds of ugly
> legacy things, like sys/sysmacros.h junk getting pulled in from
> standard headers... So far the most reasonable proposals I've seen are
> along the lines of "XSI plus some extensions" where the latter would
> correspond to _BSD_SOURCE or some analogue of _SVID_SOURCE (which is
> not supported by musl at this time).
>
> Rich

I'll repeat some followups I had on IRC here:

_XOPEN_SOURCE=700 has the advantage that it does include lots of things, 
and is a standard, so it's not an arbitrary moving target. It's probably 
not sufficient, but I'm not wholly convinced of that.

_BSD_SOURCE (which on musl apparently implies _XOPEN_SOURCE, which makes 
sense since it's not like they're not trying) is better, the only reason 
I don't like it is that it's not a standard, so there's no clear 
demarcation of what it could imply, and arbitrary new things from the 
BSDs could be added at any point. In practice this may be irrelevant 
since all the BSDs are more-or-less stagnant, but in principle it's 
iffy. I would like something like _44BSD_SOURCE only so that it's not a 
moving target, but I can see how most people would probably find that 
offensive.

I thought _SVID_SOURCE would be a reasonable intermediary because it's 
also a standard, but an olde and sort of nutty one. Upon a quick review 
of glibc's headers, there's actually very little that _SVID_SOURCE gives 
you but _XOPEN_SOURCE=700 doesn't, so it's unlikely to be very helpful. 
Besides, the STREAMS API is required in SVID, and obsolete in SUS.

With valediction,
  - Gregor Richards

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

[Rich Felker]

On Wed, Aug 29, 2012 at 10:01:29AM -0400, Gregor Richards wrote:
> I'll repeat some followups I had on IRC here:
> 
> _XOPEN_SOURCE=700 has the advantage that it does include lots of
> things, and is a standard, so it's not an arbitrary moving target.
> It's probably not sufficient, but I'm not wholly convinced of that.

At the very least, the stuff that was in _XOPEN_SOURCE=600 but removed
in 700 is probably wanted (gethostbyname, usleep, etc.).

There are also a small number of legacy interfaces that are really
only relevant to core programs: setgroups, chroot, sethostname, ...;
I'm not sure if it's really important to expose these by default if
the goal is just to avoid having to patch or add CFLAGS to _every_
program. Having to fix-up a few core programs is not such a big deal
since it's effectively O(1) effort rather than O(n).

Perhaps a bigger issue is what uglyware like GCC does when *_unlocked,
*64, etc. exist in libc but don't get exposed in the headers by
default. My leaning would be strongly against exposing this junk by
default, but I would also be interested in whether any changes we'd
make would improve the situation building GCC or make it even worse...

> _BSD_SOURCE (which on musl apparently implies _XOPEN_SOURCE, which
> makes sense since it's not like they're not trying) is better, the
> only reason I don't like it is that it's not a standard, so there's
> no clear demarcation of what it could imply, and arbitrary new
> things from the BSDs could be added at any point. In practice this
> may be irrelevant since all the BSDs are more-or-less stagnant, but
> in principle it's iffy. I would like something like _44BSD_SOURCE
> only so that it's not a moving target, but I can see how most people
> would probably find that offensive.

I think the practical difference is insufficient to matter, and
certainly insufficient to justify adding yet another feature test
macro. Since there's really little (i.e. nothing) you can rely on when
omitting all feature test macros (see the difference in how the BSDs
treat it vs what glibc does, etc.), I'm also unconvinced of the value
of trying to keep the set of functionality fixed. My practical goals
for it would be:

1. Don't bring in symbols that are likely to break real-world
software. Note that this only affects software not using feature test
macros.

2. Don't pull in ridiculous amounts of header creep where one header
includes another that includes another and you end up having macros
like major() and minor() or arch-specific CPU register names like
"eax" getting exposed in every program that includes stdlib.h...

3. Make as much software as possible "just work".

> I thought _SVID_SOURCE would be a reasonable intermediary because
> it's also a standard, but an olde and sort of nutty one. Upon a
> quick review of glibc's headers, there's actually very little that
> _SVID_SOURCE gives you but _XOPEN_SOURCE=700 doesn't, so it's
> unlikely to be very helpful. Besides, the STREAMS API is required in
> SVID, and obsolete in SUS.

If we did ever add _SVID_SOURCE, I see no reason to add STREAMS or any
other deprecated/harmful functionality. The macro would just enable
functionality that we already support that's not included in POSIX/XSI
but that was present in SVID.

Rich

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

[Bobby Bingham]

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.

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.

I vote for #1.

--
Bobby Bingham

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

[Rich Felker]

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

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

[Gregor Richards]

On 08/29/2012 11:23 AM, Rich Felker wrote:
> 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

I need to echo this sentiment, because it's important:

If you use only POSIX, then feature test macros are great. They behave 
the same everywhere and give you exactly what you want.

If you use ANY EXTENSIONS WHATSOEVER, then adding feature test macros 
WILL ASSUREDLY BREAK YOUR PROGRAM on some libc. The implementation is 
simply not consistent. The fact is, that if you want your program to be 
portable, but it requires extensions (this is not an oxymoron), then the 
proper way to go is to check for those extensions with something like 
autoconf, and then never ever set feature test macros. It's probably 
even worse than you think: The only way to figure out where or how it 
breaks your code is to try it everywhere. Thought setting _BSD_SOURCE 
was enough? Nope, you'll need at least __BSD_VISIBLE (which you're not 
supposed to touch), __EXTENSIONS__ and _DARWIN_C_SOURCE. If the feature 
test macro does not correspond to a standard, then it is a very 
effective way to shoot yourself in the foot.

Just to make this perfectly clear: If you are writing a portable program 
that, under any circumstances, uses some extension beyond POSIX, then 
adding feature test macros will break your code.

The code out there without feature test macros is not broken; it's 
portable. You can whine and moan about that state of affairs as much as 
you want, but if you actually want software to work on musl /and/ some 
other libc, then you must support this configuration.

(Please note that, in direct response to the statement I'm quoting, 
FreeBSD and Solaris are the only libcs I know of at this time that 
provide no way beyond hacks to get “the kitchen sink” back after setting 
feature test macros. You need to set at least _BSD_SOURCE, _SVID_SOURCE 
and _DARWIN_C_SOURCE to get the kitchen sink back on those that do 
support nonstandard feature test macros.)

With valediction,
  - Gregor Richards

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

[Isaac Dunham]

On Wed, 29 Aug 2012 10:01:29 -0400
Gregor Richards <gr@purdue.edu> wrote:

> On 08/29/2012 09:49 AM, Rich Felker wrote:
> > On Wed, Aug 29, 2012 at 07:34:42AM +0200, philomath wrote:
> >> On Fri, 24 Aug 2012 17:41:38 -0400
> >> Rich Felker <dalias@aerifal.cx> wrote:
> >>
> >>
> >>> 1. Leaving everything as it is.
> >>> 2. Making the kitchen sink (_GNU_SOURCE) available by default.
> >>> 3. Making only some limited subset (e.g. POSIX base) available by
> >>> default.
> >> The bikeshed should definitely not be colored black.
> >>
> >> I'd lean towards 3, 1 is fine too. but please not 2, musl's
> >> correctness is one of it's unique features...

Agreed..._GNU_SOURCE is the kitchen sink _and_ the garbage can as well.

> _XOPEN_SOURCE=700 has the advantage that it does include lots of
> things, and is a standard, so it's not an arbitrary moving target.
> It's probably not sufficient, but I'm not wholly convinced of that.

I said _XOPEN_SOURCE=600, with musl's behavior (equivalent to
_XOPEN_SOURCE=700 + obsolete extensions). There are a few extensions
that occasionally pop up.

> _BSD_SOURCE (which on musl apparently implies _XOPEN_SOURCE, which
> makes sense since it's not like they're not trying) is better, the
> only reason I don't like it is that it's not a standard, so there's
> no clear demarcation of what it could imply, and arbitrary new things
> from the BSDs could be added at any point. 
When I prepared the patch, I followed _NETBSD_SOURCE on current-ish
NetBSD.
It does (did?) not _necessarily_ imply _XOPEN_SOURCE, but there are few
places where NetBSD does not make X/Open 700 functionality available.

HTH,
Isaac Dunham

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

[Rich Felker]

On Wed, Aug 29, 2012 at 10:59:26AM -0700, Isaac Dunham wrote:
> > >>> 1. Leaving everything as it is.
> > >>> 2. Making the kitchen sink (_GNU_SOURCE) available by default.
> > >>> 3. Making only some limited subset (e.g. POSIX base) available by
> > >>> default.
> > >> The bikeshed should definitely not be colored black.
> > >>
> > >> I'd lean towards 3, 1 is fine too. but please not 2, musl's
> > >> correctness is one of it's unique features...
> 
> Agreed..._GNU_SOURCE is the kitchen sink _and_ the garbage can as well.

And glibc's version of "no feature test macros" is 90% of the garbage
can and 10% of the kitchen sink...

> > _XOPEN_SOURCE=700 has the advantage that it does include lots of
> > things, and is a standard, so it's not an arbitrary moving target.
> > It's probably not sufficient, but I'm not wholly convinced of that.
> 
> I said _XOPEN_SOURCE=600, with musl's behavior (equivalent to
> _XOPEN_SOURCE=700 + obsolete extensions). There are a few extensions
> that occasionally pop up.

Yes. If we do change things I think I'd rather have it work as
_XOPEN_SOURCE=700 + some-other-feature than _XOPEN_SOURCE=600, since
the latter is very confusing to someone readong the headers who might
think defining _XOPEN_SOUCE to 600 by default omits the SUSv4
functionality.

> > _BSD_SOURCE (which on musl apparently implies _XOPEN_SOURCE, which
> > makes sense since it's not like they're not trying) is better, the
> > only reason I don't like it is that it's not a standard, so there's
> > no clear demarcation of what it could imply, and arbitrary new things
> > from the BSDs could be added at any point. 
> When I prepared the patch, I followed _NETBSD_SOURCE on current-ish
> NetBSD.
> It does (did?) not _necessarily_ imply _XOPEN_SOURCE, but there are few
> places where NetBSD does not make X/Open 700 functionality available.

I'm not sure what the current state is, but my preference (in the
absence of other considerations) would be for it to include everything
from XSI that's actually desirable, possibly omitting legacy, useless,
and nonsensical stuff.

Rich

Re: Best bikeshed ever (feature test macros)

[Arvid E. Picciani]

Heya,

i'm a bit confused over 1 vs 2.

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?






(as for the opinion part: i don't work on GNU/Crap so almost all of the 
software i use musl with works fine now)



-- 
Arvid E. Picciani

Re: Best bikeshed ever (feature test macros)

[Rich Felker]

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

Re: Best bikeshed ever (feature test macros)

[Arvid E. Picciani]

On Sun, 2 Sep 2012 11:19:18 -0400, Rich Felker wrote:

> 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.

I see, thanks. But then there is no software that benefits from the 
default kitchen sink.
So it seems like a pseudo option put up just to show how bad it is :)


-- 
Arvid E. Picciani

Re: Best bikeshed ever (feature test macros)

[Rich Felker]

On Sun, Sep 02, 2012 at 05:27:26PM +0200, Arvid E. Picciani wrote:
> On Sun, 2 Sep 2012 11:19:18 -0400, Rich Felker wrote:
> 
> >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.
> 
> I see, thanks. But then there is no software that benefits from the
> default kitchen sink.
> So it seems like a pseudo option put up just to show how bad it is :)

Well, glibc seems to be the only major system that's essentially
locked the default profile to a certain point in history, and forced
the use of a feature test macro to access even its own newer features.
Most of the BSDs reportedly make (their version of) the kitchen sink
available by default, so such a behavior might be more compatible with
certain software that was intended only for use on BSD.

Aside from that, I agree that option 2 is mostly a pseudo-option.

Rich

Re: Best bikeshed ever (feature test macros)

[nwmcsween]

On Aug 24, 2012, at 2:41 PM, Rich Felker <dalias@aerifal.cx> wrote:

> Hi all,
> 
> Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -D_GNU_SOURCE,
> etc. things everybody gets wrong) have been one of the more
> controversial aspects of musl, particularly the fact that musl
> presents by default a straight ISO C conforming environment with no
> POSIX, traditional Unix, etc. stuff offending the pristine C
> namespace, and requires the use of one or more feature test macros to
> get basically _ANY_ typical unixy software to build.
> 
> There's been some (mostly dead-end) discussion over the past few weeks
> from folks who are unhappy with this situation or want it to change; I
> suspect there are also some purists who want every application out
> there to change and make explicit what features it depends on.
> 
> In this thread I'd like to gauge opinions on the matter. In other
> words, this is the ultimate bikeshed thread.
> 
> To give it some direction, I'd like to start off with some pros and
> cons of the different options...
> 
> 
> 1. Leaving everything as it is.
> 
> PROS: Obtaining conforming standard C environment is easy. Detecting
> (for the purpose of flaming or fixing) programs failing to use feature
> test macros correctly is also easy.
> 
> CONS: Basically every program requires a feature test macro to be
> added to CFLAGS in order to compile it. 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 or similar by
> introducing nonstandard functions that pollute the namespace and
> conflict with the application. Thus it becomes really hard to have a
> universal working build procedure. It's also very hard to work around
> broken build systems (like GCC's bootstrapping) that refuse to honor
> your custom CFLAGS.
> 
> 
> 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.
> 
> CONS: The preprocessor logic in the headers becomes MUCH uglier. And
> purists may object to this on moral grounds.
> 
> 
> 3. Making only some limited subset (e.g. POSIX base) available by
> default.
> 
> PROS: Easy to do, e.g. by adding "|| !defined(__STRICT_ANSI__)" to all
> POSIX functionality #ifs. Cannot break any correct code in the default
> configuration except pure ISO C code that's non-POSIX, and even then,
> -std=c99 fixes it. Might cause applications to be built with less GNU
> interface dependencies.
> 
> CONS: Probably fails to get a significant portion of apps working.
> 
> 
> Much like the last thread I created to assess opinion (the license
> one), this is all fairly open-ended and not necessarily going to lead
> to any short- or long-term change in direction, but then again it
> could... Replies don't have to be of the form 1/2/3; alternative ideas
> are welcome, as are replies that just address which goals/criteria are
> most important to you.
> 
> Rich

Leave it as is, this actually helps find bugs in software. A real world example is  accidentally utilizing gnu extensions in mruby (see github mruby bug page for more info).

Re: Best bikeshed ever (feature test macros)

[Gregor Richards]

On 09/02/2012 01:00 PM, nwmcsween@gmail.com wrote:
> On Aug 24, 2012, at 2:41 PM, Rich Felker <dalias@aerifal.cx> wrote:
>
>> Hi all,
>>
>> Feature test macros (the fun -D_POSIX_C_SOURCE=200809L, -D_GNU_SOURCE,
>> etc. things everybody gets wrong) have been one of the more
>> controversial aspects of musl, particularly the fact that musl
>> presents by default a straight ISO C conforming environment with no
>> POSIX, traditional Unix, etc. stuff offending the pristine C
>> namespace, and requires the use of one or more feature test macros to
>> get basically _ANY_ typical unixy software to build.
>>
>> There's been some (mostly dead-end) discussion over the past few weeks
>> from folks who are unhappy with this situation or want it to change; I
>> suspect there are also some purists who want every application out
>> there to change and make explicit what features it depends on.
>>
>> In this thread I'd like to gauge opinions on the matter. In other
>> words, this is the ultimate bikeshed thread.
>>
>> To give it some direction, I'd like to start off with some pros and
>> cons of the different options...
>>
>>
>> 1. Leaving everything as it is.
>>
>> PROS: Obtaining conforming standard C environment is easy. Detecting
>> (for the purpose of flaming or fixing) programs failing to use feature
>> test macros correctly is also easy.
>>
>> CONS: Basically every program requires a feature test macro to be
>> added to CFLAGS in order to compile it. 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 or similar by
>> introducing nonstandard functions that pollute the namespace and
>> conflict with the application. Thus it becomes really hard to have a
>> universal working build procedure. It's also very hard to work around
>> broken build systems (like GCC's bootstrapping) that refuse to honor
>> your custom CFLAGS.
>>
>>
>> 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.
>>
>> CONS: The preprocessor logic in the headers becomes MUCH uglier. And
>> purists may object to this on moral grounds.
>>
>>
>> 3. Making only some limited subset (e.g. POSIX base) available by
>> default.
>>
>> PROS: Easy to do, e.g. by adding "|| !defined(__STRICT_ANSI__)" to all
>> POSIX functionality #ifs. Cannot break any correct code in the default
>> configuration except pure ISO C code that's non-POSIX, and even then,
>> -std=c99 fixes it. Might cause applications to be built with less GNU
>> interface dependencies.
>>
>> CONS: Probably fails to get a significant portion of apps working.
>>
>>
>> Much like the last thread I created to assess opinion (the license
>> one), this is all fairly open-ended and not necessarily going to lead
>> to any short- or long-term change in direction, but then again it
>> could... Replies don't have to be of the form 1/2/3; alternative ideas
>> are welcome, as are replies that just address which goals/criteria are
>> most important to you.
>>
>> Rich
> Leave it as is, this actually helps find bugs in software. A real world example is  accidentally utilizing gnu extensions in mruby (see github mruby bug page for more info).
The same can be accomplished on any modern libc by using -std=c89 or 
-std=c99. You shouldn't have to port to a new libc to find these 
problems, nor should said new libc be designed in such a way that the 
majority of software doesn't work on it without additional complication. 
Especially when, as I will repeat over and over again, going through the 
additional complication to supposedly make your code more portable WILL 
INVARIABLY MAKE YOUR CODE LESS PORTABLE.

With valediction,
  - Gregor Richards

Re: Best bikeshed ever (feature test macros)

[Rich Felker]

On Sun, Sep 02, 2012 at 01:06:25PM -0400, Gregor Richards wrote:
> >Leave it as is, this actually helps find bugs in software. A real
> >world example is accidentally utilizing gnu extensions in mruby
> >(see github mruby bug page for more info).
> 
> The same can be accomplished on any modern libc by using -std=c89 or
> -std=c99. You shouldn't have to port to a new libc to find these

I'm a bit confused because I suspect the code in question actually
wanted POSIX, not just baseline C...

> problems, nor should said new libc be designed in such a way that
> the majority of software doesn't work on it without additional
> complication. Especially when, as I will repeat over and over again,
> going through the additional complication to supposedly make your
> code more portable WILL INVARIABLY MAKE YOUR CODE LESS PORTABLE.

This only applies if you're using extensions. And actually, I'm not
sure it's the case. If you add -D_GNU_SOURCE (and no other feature
test macros), does that really _hide_ any interfaces on BSD, Darwin,
Solaris, or other relevant systems?

Rich

Re: Best bikeshed ever (feature test macros)

[Gregor Richards]

On 09/02/2012 01:13 PM, Rich Felker wrote:
> On Sun, Sep 02, 2012 at 01:06:25PM -0400, Gregor Richards wrote:
>>> Leave it as is, this actually helps find bugs in software. A real
>>> world example is accidentally utilizing gnu extensions in mruby
>>> (see github mruby bug page for more info).
>> The same can be accomplished on any modern libc by using -std=c89 or
>> -std=c99. You shouldn't have to port to a new libc to find these
> I'm a bit confused because I suspect the code in question actually
> wanted POSIX, not just baseline C...
>
>> problems, nor should said new libc be designed in such a way that
>> the majority of software doesn't work on it without additional
>> complication. Especially when, as I will repeat over and over again,
>> going through the additional complication to supposedly make your
>> code more portable WILL INVARIABLY MAKE YOUR CODE LESS PORTABLE.
> This only applies if you're using extensions. And actually, I'm not
> sure it's the case. If you add -D_GNU_SOURCE (and no other feature
> test macros), does that really _hide_ any interfaces on BSD, Darwin,
> Solaris, or other relevant systems?
>
> Rich

Yes, it only applies if you're using extensions. If you're not, you 
really, REALLY should have _POSIX_C_SOURCE or _XOPEN_SOURCE set. My 
point is about portably using extensions (this is not an oxymoron).

Last I checked, -D_GNU_SOURCE exposes broken functions on certain BSDs. 
I remember having to make a very careful set of feature test macros to 
get one extension if available, but NOT make the BSDs give me a broken 
function otherwise. That was a while ago and I don't remember what 
function it was, I'm afraid. Ironically, the function wasn't even broken 
in glibc. More to the point, since they do recognize _GNU_SOURCE, it 
leads them through their entire feature macro song and dance; I'm not 
sure if it actually hides anything, but it wouldn't surprise me if it does.

More importantly, that's just philosophically walking in circles. You'd 
use _GNU_SOURCE because it's what musl needs, but if somebody wrote 
their new fancy libc under the same principle and decided they didn't 
like _GNU_SOURCE, you'd need _BSD_SOURCE there, and that drags you 
through a different hell elsewhere. You're playing a game of who's-who 
with nonstandard macros.

With valediction,
  - Gregor Richards

Re: Best bikeshed ever (feature test macros)

[Rich Felker]

On Sun, Sep 02, 2012 at 10:00:27AM -0700, nwmcsween@gmail.com wrote:
> > Much like the last thread I created to assess opinion (the license
> > one), this is all fairly open-ended and not necessarily going to lead
> > to any short- or long-term change in direction, but then again it
> > could... Replies don't have to be of the form 1/2/3; alternative ideas
> > are welcome, as are replies that just address which goals/criteria are
> > most important to you.
> 
> Leave it as is, this actually helps find bugs in software. A real
> world example is accidentally utilizing gnu extensions in mruby (see
> github mruby bug page for more info).

I'm glad to hear of a real-world example where somebody was actually
happy about catching bugs like this. However I don't see how the
current default contributes to finding such bugs. If you're compiling
an app that's targetting POSIX or POSIX+XSI portability, the current
default will not handle that; you need to add feature test macros like
-D_POSIX_C_SOURCE=200809L, and that would work just as well if we
changed the default. Or do you mean to say that the fact that it broke
by default prompted you to add -D_POSIX_C_SOURCE=200809L manually, and
then when you tried compiling again and got an error message, you
realized the issue was a GNU extension that was being used?

Can you clarify? As I'm reading the situation, it sounds to me like
providing POSIX or POSIX+XSI by default would be just as likely to
catch such bugs (if nor moreso, since it would eliminate the case
where somebody adds -D_GNU_SOURCE "just to be safe").

Rich