Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 29 Aug 2012 10:01:29 -0400
From: Gregor Richards <>
Subject: Re: Re: Best bikeshed ever (feature test macros)

On 08/29/2012 09:49 AM, Rich Felker wrote:
> On Wed, Aug 29, 2012 at 07:34:42AM +0200, philomath wrote:
>> On Fri, 24 Aug 2012 17:41:38 -0400
>> Rich Felker <> wrote:
>>> 1. Leaving everything as it is.
>>> 2. Making the kitchen sink (_GNU_SOURCE) available by default.
>>> 3. Making only some limited subset (e.g. POSIX base) available by
>>> default.
>> The bikeshed should definitely not be colored black.
>> I'd lean towards 3, 1 is fine too. but please not 2, musl's
>> correctness is one of it's unique features...
>> Thanks.
> Thanks for the input. What correctness aspect is important to you? I
> conceptually like the minimal-by-default namespace, but ISO C does not
> specify how to invoke the compiler, so even implementations that
> require you to use obscure options to get a clean plain-C namespace
> are "correct". In practice, any of the options 1-3 would give the
> clean namespace as long as -std=c* is used with no feature test
> macros.
> With that said, I do tend to agree that option 2 is ugly, mainly since
> it exposes not just useful modern extensions but all kinds of ugly
> legacy things, like sys/sysmacros.h junk getting pulled in from
> standard headers... So far the most reasonable proposals I've seen are
> along the lines of "XSI plus some extensions" where the latter would
> correspond to _BSD_SOURCE or some analogue of _SVID_SOURCE (which is
> not supported by musl at this time).
> Rich

I'll repeat some followups I had on IRC here:

_XOPEN_SOURCE=700 has the advantage that it does include lots of things, 
and is a standard, so it's not an arbitrary moving target. It's probably 
not sufficient, but I'm not wholly convinced of that.

_BSD_SOURCE (which on musl apparently implies _XOPEN_SOURCE, which makes 
sense since it's not like they're not trying) is better, the only reason 
I don't like it is that it's not a standard, so there's no clear 
demarcation of what it could imply, and arbitrary new things from the 
BSDs could be added at any point. In practice this may be irrelevant 
since all the BSDs are more-or-less stagnant, but in principle it's 
iffy. I would like something like _44BSD_SOURCE only so that it's not a 
moving target, but I can see how most people would probably find that 

I thought _SVID_SOURCE would be a reasonable intermediary because it's 
also a standard, but an olde and sort of nutty one. Upon a quick review 
of glibc's headers, there's actually very little that _SVID_SOURCE gives 
you but _XOPEN_SOURCE=700 doesn't, so it's unlikely to be very helpful. 
Besides, the STREAMS API is required in SVID, and obsolete in SUS.

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.