Date: Sun, 2 Sep 2012 10:00:27 -0700 From: nwmcsween@...il.com To: "musl@...ts.openwall.com" <musl@...ts.openwall.com> Subject: Re: Best bikeshed ever (feature test macros) 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).
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.