Date: Sun, 2 Sep 2012 11:19:18 -0400 From: Rich Felker <dalias@...ifal.cx> To: musl@...ts.openwall.com Subject: Re: Best bikeshed ever (feature test macros) On Sun, Sep 02, 2012 at 10:48:13AM +0200, Arvid E. Picciani wrote: > Heya, > > i'm a bit confused over 1 vs 2. With option 1 (leaving things as-is), invoking the compiler with no feature test macros gives the same effect as invoking "gcc -std=c99" on glibc: only stuff from plain C is visible. It's pretty much impossible to find or write software where this mode has any practical value, so the only values of option 1 are: - The ideological purity of providing a straight conforming C environment by default - Breaking "bad software" that's failing to use feature test macros to request the functionality it needs. It's the latter of these two points that seems to be the point of interest and controversy. On the one hand, there's the argument that programs that want to use whatever extension features the system offers cannot portably request this; there are systems where ANY use of feature test macros removes some extensions that are visible by default, and provides no way to get them back. On the other hand, relying on the default environment to be sane is fundamentally broken. For example, glibc by default gives you an incorrect version of strerror_r that doesn't even have the right prototype, and misbehaving versions of basename, scanf, and other functions. I'm pretty sure that at one point, certain proprietary unices like Solaris were even worse, providing horribly non-conforming legacy environments with bug-compatibility for legacy versions unless you used the right feature test macros. No idea if they've all been fixed or if they're even still relevant. At this point it sounds like programs that are omitting all feature test macros by default are hopelessly broken and not even worth trying to support. However, the fact of the matter is that they "work" on a large portion of systems, and on systems where the above issues are show-stoppers, you can _add_ some feature test macros (rather than having to remove them) to get the app to work. Right now, we're in the situation where musl is one of the systems where such apps don't work, and the issue can be solved by adding -D_GNU_SOURCE (or often just a POSIX/XSI feature). The question is whether it would be more valuable to change things so that musl is a system where the default environment is "just working" even better than glibc's (by virtue of exposing all the useful extensions but not doing broken things like exposing the wrong versions of strerror_r, basename, etc.). > On Fri, 24 Aug 2012 17:41:38 -0400, Rich Felker wrote: > > >Using -D_GNU_SOURCE works 99% > >of the time, but the other 1% of the time it will _break_ programs > >that are already correctly using -D_XOPEN_SOURCE=700 > > > >2. Making the kitchen sink (_GNU_SOURCE) available by default. > > > >PROS: Works with most software and won't break software that's > >already > >correctly using feature test macros. > > I see how _GNU_SOURCE breaks stuff, but how does it not break if its > the default? If software is already correctly using feature test macros, it's getting an environment it selected, not the default environment, so changing the default will have no effect on such software. 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.