[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120827110830.43d1a74a@newbook>
Date: Mon, 27 Aug 2012 11:08:30 -0700
From: Isaac Dunham <idunham@...abit.com>
To: musl@...ts.openwall.com
Subject: Re: Best bikeshed ever (feature test macros)
On Fri, 24 Aug 2012 17:41:38 -0400
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.
I have built a few programs without extra CFLAGS.
(two of them being nebula & cmix)
>
> 1. Leaving everything as it is.
>
>
> 2. Making the kitchen sink (_GNU_SOURCE) available by default.
This can be done the same way as 3, but it does mean a lot of extra
verbiage in the headers.
Name collisions are something I've run into, though they're fairly
trivial to fix in my experience.
All told, I'd say it's practical but maybe not desirable.
And if you *are* going to make everything available, also make the
strl* functions and fgetln available, so software doesn't pull in its
own version due to broken tests (haven't noticed this happening,
but...).
> 3. Making only some limited subset (e.g. POSIX base) available by
> default.
I'd prefer some variant of 3. And the _XOPEN_SOURCE=600 || _BSD_SOURCE
suggestion does sound fairly reasonable except for some headers, like
<math.h>
Isaac Dunham
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.
