[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
