[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120829144347.GU27715@brightrain.aerifal.cx>
Date: Wed, 29 Aug 2012 10:43:47 -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:01:29AM -0400, Gregor Richards wrote:
> 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.
At the very least, the stuff that was in _XOPEN_SOURCE=600 but removed
in 700 is probably wanted (gethostbyname, usleep, etc.).
There are also a small number of legacy interfaces that are really
only relevant to core programs: setgroups, chroot, sethostname, ...;
I'm not sure if it's really important to expose these by default if
the goal is just to avoid having to patch or add CFLAGS to _every_
program. Having to fix-up a few core programs is not such a big deal
since it's effectively O(1) effort rather than O(n).
Perhaps a bigger issue is what uglyware like GCC does when *_unlocked,
*64, etc. exist in libc but don't get exposed in the headers by
default. My leaning would be strongly against exposing this junk by
default, but I would also be interested in whether any changes we'd
make would improve the situation building GCC or make it even worse...
> _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 think the practical difference is insufficient to matter, and
certainly insufficient to justify adding yet another feature test
macro. Since there's really little (i.e. nothing) you can rely on when
omitting all feature test macros (see the difference in how the BSDs
treat it vs what glibc does, etc.), I'm also unconvinced of the value
of trying to keep the set of functionality fixed. My practical goals
for it would be:
1. Don't bring in symbols that are likely to break real-world
software. Note that this only affects software not using feature test
macros.
2. Don't pull in ridiculous amounts of header creep where one header
includes another that includes another and you end up having macros
like major() and minor() or arch-specific CPU register names like
"eax" getting exposed in every program that includes stdlib.h...
3. Make as much software as possible "just work".
> 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.
If we did ever add _SVID_SOURCE, I see no reason to add STREAMS or any
other deprecated/harmful functionality. The macro would just enable
functionality that we already support that's not included in POSIX/XSI
but that was present in SVID.
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.
