[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <50439211.6050504@purdue.edu>
Date: Sun, 02 Sep 2012 13:06:25 -0400
From: Gregor Richards <gr@...due.edu>
To: musl@...ts.openwall.com
Subject: Re: Best bikeshed ever (feature test macros)
On 09/02/2012 01:00 PM, nwmcsween@...il.com wrote:
> On Aug 24, 2012, at 2:41 PM, 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
> 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
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.
