Re: Best bikeshed ever (feature test macros)

[Gregor Richards <gr@purdue.edu>]

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