Re: Add _DEFAULT_SOURCE feature test macro.

[Rich Felker <dalias at aerifal dot cx>]

On Tue, Dec 17, 2013 at 10:00:40PM +0000, Joseph S. Myers wrote:
> There are hundreds of __USE_GNU conditionals - for a long time it's been 
> the normal conditional for anything new and non-POSIX added to a header - 
> so I don't think such an analysis would be particularly meaningful.
> 
> This patch adds a feature test macro _DEFAULT_SOURCE to enable the
> default set of header declarations.
> 
> The intention is: if _DEFAULT_SOURCE is not used there is no change to
> the set of __USE_* macros glibc defines; if it's used on its own, and
> without compiler options such as -std=c99 that define __STRICT_ANSI__,
> again, there is no change; if it's used together with the macros it
> approximately (i.e., apart from __USE_POSIX_IMPLICITLY) implies
> (-D_BSD_SOURCE -D_SVID_SOURCE -D_POSIX_C_SOURCE=200809L), again, there
> is no change.  Otherwise, it causes the relevant features to be
> enabled, even if __STRICT_ANSI__, or another feature test macro, would
> cause them to be disabled.
> 
> This macro deliberately bundles the POSIX.1-2008 (non-X/Open)
> functionality with the BSD/SVID/"misc" functionality, rather than
> defining a macro that gives just the latter, as many of the header
> cleanups resulting from removing _BSD_SOURCE and _SVID_SOURCE support
> are only possible when BSD/SVID/"misc" is always bundled with
> POSIX.1-2008.

To me this sounds like just about the ideal behavior. BTW I think it
also brings glibc's defaults closer to the defaults we're providing in
musl. We don't have a SVID switch at all, but the defaults include
(our version of) BSD and XOPEN (so, still a little bit more than
glibc's defaults probably) and between those two we also get
everything that would have been under SVID.

If everybody is happy with the "_DEFAULT_SOURCE" name I'll adopt it in
musl too and propose that uclibc do the same too, in the interest of
making it something that apps can somewhat rely upon across several
implementations (well, somewhere down the line once everybody has
upgraded to recent versions).

BTW one other idea I'd like to propose for consideration along with
this change is some way for requesting "POSIX future" functionality or
even making it available by default. (Things like dup3, pipe2,
posix_close, etc.) Perhaps the most logical way to do this would be
making _POSIX_C_SOURCE > 200809L give POSIX-future, and defining
_POSIX_C_SOURCE to something greater than the current version when
_DEFAULT_SOURCE is used. I have not thought through all the
consequences of this yet though.

Rich