[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Sun, 02 Sep 2012 13:18:54 -0400
From: Gregor Richards <gr@...due.edu>
To: musl@...ts.openwall.com
Subject: Re: Best bikeshed ever (feature test macros)
On 09/02/2012 01:13 PM, Rich Felker wrote:
> On Sun, Sep 02, 2012 at 01:06:25PM -0400, Gregor Richards wrote:
>>> Leave it as is, this actually helps find bugs in software. A real
>>> world example is accidentally utilizing gnu extensions in mruby
>>> (see github mruby bug page for more info).
>> The same can be accomplished on any modern libc by using -std=c89 or
>> -std=c99. You shouldn't have to port to a new libc to find these
> I'm a bit confused because I suspect the code in question actually
> wanted POSIX, not just baseline C...
>
>> problems, nor should said new libc be designed in such a way that
>> the majority of software doesn't work on it without additional
>> complication. Especially when, as I will repeat over and over again,
>> going through the additional complication to supposedly make your
>> code more portable WILL INVARIABLY MAKE YOUR CODE LESS PORTABLE.
> This only applies if you're using extensions. And actually, I'm not
> sure it's the case. If you add -D_GNU_SOURCE (and no other feature
> test macros), does that really _hide_ any interfaces on BSD, Darwin,
> Solaris, or other relevant systems?
>
> Rich
Yes, it only applies if you're using extensions. If you're not, you
really, REALLY should have _POSIX_C_SOURCE or _XOPEN_SOURCE set. My
point is about portably using extensions (this is not an oxymoron).
Last I checked, -D_GNU_SOURCE exposes broken functions on certain BSDs.
I remember having to make a very careful set of feature test macros to
get one extension if available, but NOT make the BSDs give me a broken
function otherwise. That was a while ago and I don't remember what
function it was, I'm afraid. Ironically, the function wasn't even broken
in glibc. More to the point, since they do recognize _GNU_SOURCE, it
leads them through their entire feature macro song and dance; I'm not
sure if it actually hides anything, but it wouldn't surprise me if it does.
More importantly, that's just philosophically walking in circles. You'd
use _GNU_SOURCE because it's what musl needs, but if somebody wrote
their new fancy libc under the same principle and decided they didn't
like _GNU_SOURCE, you'd need _BSD_SOURCE there, and that drags you
through a different hell elsewhere. You're playing a game of who's-who
with nonstandard macros.
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.
