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.