[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120829180815.GZ27715@brightrain.aerifal.cx>
Date: Wed, 29 Aug 2012 14:08:15 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: Re: Best bikeshed ever (feature test macros)
On Wed, Aug 29, 2012 at 10:59:26AM -0700, Isaac Dunham 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...
>
> Agreed..._GNU_SOURCE is the kitchen sink _and_ the garbage can as well.
And glibc's version of "no feature test macros" is 90% of the garbage
can and 10% of the kitchen sink...
> > _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.
>
> I said _XOPEN_SOURCE=600, with musl's behavior (equivalent to
> _XOPEN_SOURCE=700 + obsolete extensions). There are a few extensions
> that occasionally pop up.
Yes. If we do change things I think I'd rather have it work as
_XOPEN_SOURCE=700 + some-other-feature than _XOPEN_SOURCE=600, since
the latter is very confusing to someone readong the headers who might
think defining _XOPEN_SOUCE to 600 by default omits the SUSv4
functionality.
> > _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.
> When I prepared the patch, I followed _NETBSD_SOURCE on current-ish
> NetBSD.
> It does (did?) not _necessarily_ imply _XOPEN_SOURCE, but there are few
> places where NetBSD does not make X/Open 700 functionality available.
I'm not sure what the current state is, but my preference (in the
absence of other considerations) would be for it to include everything
from XSI that's actually desirable, possibly omitting legacy, useless,
and nonsensical stuff.
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.
