This is the mail archive of the
mailing list for the glibc project.
Re: Remove _BSD_SOURCE and _SVID_SOURCE
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Mon, 16 Dec 2013 14:53:38 -0800 (PST)
- Subject: Re: Remove _BSD_SOURCE and _SVID_SOURCE
- Authentication-results: sourceware.org; auth=none
- References: <Pine dot LNX dot 4 dot 64 dot 1312052315530 dot 16480 at digraph dot polyomino dot org dot uk>
I think appropriate conservatism is to start with a change that just
eliminates __FAVOR_BSD. We might even want to go through a release
cycle like that (but maybe not).
In the past, I'm pretty sure I've seen (non-GNU) packages that use
-D_BSD_SOURCE -D_SVID_SOURCE to get "common" extensions without getting
GNU extensions (some of which have names that might be more likely to
have been used by applications--getline was a common case, at least
before it was added to POSIX). So perhaps there is a need for something
like that. I guess we could start (after removing __FAVOR_BSD stuff)
with an analysis of what names are enabled by _GNU_SOURCE but not the
I'm not really sure exactly how to proceed. But I think it needs to be
more conservative and incremental than this change looks to me off hand.
I think the suggestion of a feature-test macro that enables all the
extension symbols but does not change any standard-specified symbols has
merit. It is probably wise to add this first, and then stage the
removal of the old feature-test macros. A long-term intermediate state
that probably makes sense is to have _BSD_SOURCE and _SVID_SOURCE
(without _GNU_SOURCE) trigger this new mode but with a #warning advising
to use the cleaner new feature-test macro name.