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.