Re: Best bikeshed ever (feature test macros)

[orc <orc@sibserver.ru>]

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