Re: Remove _BSD_SOURCE and _SVID_SOURCE

[OndÅej BÃlka <neleai at seznam dot cz>]

On Thu, Dec 05, 2013 at 11:17:59PM +0000, Joseph S. Myers wrote:
> This patch removes support for the _BSD_SOURCE and _SVID_SOURCE
> feature test macros, as suggested by Roland in
> <https://sourceware.org/ml/libc-alpha/2013-04/msg00355.html>; it also
> removes the libbsd-compat library (which has long been a dummy library
> not doing anything, but was documented as if it did something).  It
> does not obsolete any APIs enabled by those macros, except for
> __FAVOR_BSD features no longer being available (anonymous unions are
> used as Roland suggested for struct tcphdr/udphdr, as it appears
> _BSD_SOURCE is actually being used in practice to enable the BSD names
> there - it may be necessary to condition the anonymous unions in some
> way depending on compiler support).
> 
> If anyone wishes to obsolete any BSD/SVID APIs, all conditioned by
> __USE_MISC after this patch, or to restrict any of them to
> _GNU_SOURCE, or to change conditions such as __USE_MISC ||
> __USE_UNIX98 to remove the __USE_MISC case so the APIs aren't visible
> by default, such changes should be proposed separately for particular
> APIs or groups of APIs in separate threads.  (Obsoleting an API would
> mean removing header definitions associated with it and making the
> exported symbols into compat symbols only available for existing
> binaries.  Or, there could be two-stage obsoletion, first marking
> functions with "deprecated" attributes and only later or never making
> them into compat symbols.)
> 
> In more detail:
> 
> The status quo is that the features enabled by _BSD_SOURCE or
> _SVID_SOURCE are enabled (a) if the applicable one of those macros is
> defined by the user (a case that will no longer be supported), (b) by
> default, if the user didn't use a compiler option such as -ansi or
> -std=c99 that defines __STRICT_ANSI__ and didn't define
> _ISOC99_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE or _XOPEN_SOURCE (or
> _BSD_SOURCE or _SVID_SOURCE), (c) if _GNU_SOURCE is defined.  There's
> the oddity of (b) not checking _ISOC11_SOURCE, but it's not the
> function of this patch to change anything in that regard.
> 
> The patch retains the status quo for cases not defining _BSD_SOURCE or
> _SVID_SOURCE - that is, enabling the relevant features if _GNU_SOURCE
> is defined or none of the other macros are defined to disable them.
> If none of the macros are defined that would disable those features,
> it is also the case that _POSIX_C_SOURCE is defined by features.h to
> 200809L, and that's the case for _GNU_SOURCE as well.  Thus, all of
> __USE_POSIX, __USE_POSIX2, __USE_POSIX199309, __USE_POSIX199506,
> __USE_XOPEN2K, __USE_ISOC95, __USE_ISOC99, __USE_XOPEN2K8,
> __USE_ATFILE are also defined, and any conditionals that enable a
> feature for (__USE_X || __USE_MISC), for __USE_X being one of those
> macros, can be simplified accordingly not to mention __USE_MISC, and
> this patch makes those simplifications (whether or not the particular
> __USE_MISC uses in question arose from conversion of __USE_BSD and
> __USE_SVID - the *redundancy* of __USE_MISC still arises from this
> patch, by eliminating the previous ways of getting __USE_MISC defined
> without the other features).  The other way round, "__USE_MISC ||
> __USE_GNU" can just test __USE_MISC.
> 
> I should note that I'm unconvinced that the original intent of using
> only a single __USE_* macro in any given place is a good idea for the
> set of standards we support today; if something is present in all
> standards based on Unix98 or C99, "defined __USE_UNIX98 || defined
> __USE_ISOC99" seems like a perfectly reasonable way to express things
> and a macro for the combination just seems like undue complication.  I
> do expect there are lots of places where the combinations used can in
> fact be simplified, using the rules about which standard imply which
> others, and more simplification may be possible if the only standards
> defining a given header are based on standard X and so we can just
> assume X is enabled within that header.
> 
> The BSD sigpause function is made unavailable by this patch.  Arguably
> it should be made a compat symbol, with the POSIX version getting the
> sigpause name at a new symbol version rather than relying on
> redirection to __xpg_sigpause (which itself would also become a compat
> symbol), since the function meets the criteria for being callable
> without including a header (no types defined in headers are involved
> in the function type), but this patch does not do that (I propose to
> file a bug in Bugzilla for it).
> 
> The setjmp function declared in headers is the BSD version and the
> setjmp macro that hides it maps it to _setjmp.  Arguably the exported
> setjmp function (defined in bsd-setjmp.[cS] for each architecture)
> should also be made a compat symbol and no longer declared in the
> header (and not provided for new ports); ISO C makes it undefined
> behavior to undefine a setjmp macro to access any underlying function.
> I propose filing a bug in Bugzilla for that as well.
> 
> Tested x86_64 and x86.
> 

What script did you used? As this is big patch I want to distinguish
between parts that can be checked automatically from manual changes.

So far I come with

sed -e"s/_USE_SVID/_USE_MISC/" | sed  -e"s/_USE_BSD/_USE_MISC/" | sed -e"s/_USE_POSIX || _USE_MISC/_USE_POSIX/" | sed -e"s/_USE_MISC || _USE_POSIX/_USE_POSIX/"

and when I diff that vs your patch result is still big.