[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120825153556.20782684@sibserver.ru>
Date: Sat, 25 Aug 2012 15:35:56 +0800
From: orc <orc@...server.ru>
To: musl@...ts.openwall.com
Subject: Re: Best bikeshed ever (feature test macros)
On Fri, 24 Aug 2012 17:41:38 -0400
Rich Felker <dalias@...ifal.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).
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.
