[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <503E20B9.7060705@purdue.edu>
Date: Wed, 29 Aug 2012 10:01:29 -0400
From: Gregor Richards <gr@...due.edu>
To: musl@...ts.openwall.com
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 <dalias@...ifal.cx> 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
offensive.
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.
