Date: Fri, 24 Aug 2012 17:41:38 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Best bikeshed ever (feature test macros) 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
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.