Re: [Jim Meyering] Re: [Bug-gnulib] strftime merge from Emacs

[Paul Eggert <eggert@CS.UCLA.EDU>]

Dave Love <d.love@dl.ac.uk> writes:

> Surely it's incorrect not to use them if you want to use the features?

The usual tradition is that hosts enable all extensions unless you
specifically ask that extensions be disabled.  Some hosts don't follow
this tradition: instead, they enable only a standard subset by
default, and you have to define some nonstandard feature-test macro
like __EXTENSIONS__ or _GNU_SOURCE in order to enable all extensions.
For such systems, it's obviously OK to define _GNU_SOURCE etc., as
that's the way to say "I want all extensions", which is the normal
thing that Autoconfed packages want to say.

However, I've found that it's usually a mistake to play with
feature-test macros any more than that.  In other words, it's usually
a mistake to futz with more-specific feature-test macros like
_XOPEN_SOURCE and _POSIX_SOURCE.  This is for two reasons.  First,
these macros generally disable some extensions, and that's not what
Autoconfized packages usually want.  Second, these macros are rarely
used, so their use often triggers bugs in headers.


> I'm thinking of things like _XOPEN_SOURCE, which won't disable much.

And I'm also thinking of things like _XOPEN_SOURCE.  For example,
AC_SYS_LARGEFILE used to "#define _XOPEN_SOURCE 500" when it detected
a certain bug in glibc 2.1.3, to work around that bug.  (The bug was
that glibc did not declare fseeko unless you defined _XOPEN_SOURCE.)
But this caused far too many other problems in practice: it disabled
many other useful extensions.  When AC_SYS_LARGEFILE stopped mucking
with _XOPEN_SOURCE, the problems largely went away, and this was a win
overall.