Remove _BSD_SOURCE and _SVID_SOURCE

[Joseph S. Myers]

On Tue, 11 Feb 2014, Roland McGrath wrote:

> I think before we simplify the __USE_* macro set, we should first use it as
> a pointer toward obsolete interfaces we can deprecate or remove.  sigvec

I think __USE_BSD, __USE_SVID and __USE_MISC are all about equally good at 
indicating interfaces to remove, and so simplifying the set first makes 
the review process simpler (some cases that were e.g. __USE_MISC || 
__USE_POSIX get simplified not to refer to __USE_MISC at all so they then 
don't need considering in any review of interfaces).  There may also be a 
few __USE_GNU interfaces that should be removed.

What are recommended ways to check for users of a particular interface, 
since Google Code Search was shut down?  (codesearch.debian.net is rather 
less than ideal for this purpose because it's liable to show huge numbers 
of references to a symbol in glibc ABI baselines etc. when what you want 
it uses in other packages only, and there isn't an obvious way to exclude 
a given package from a search.)

When an interface is deprecated, there is the question of whether we want 
to keep any testcases that verify the compat symbols work (such tests 
could of course only be run on architectures that have the symbols at all, 
not new architectures without them), and if so, how to build / link such 
tests (we have some special measures for testing sunrpc via linking with 
linkobj/libc.so).

> and some of the other pre-POSIX signal functions come to mind.  Also
> sys_errlist et al, since everything should be using strerror/strsigal by
> now.  And audit of the exported symbols would be good.

One thing I had in mind was eliminating (i.e. preventing newly linked 
programs from using) the SVID matherr mechanism for libm error handling 
and the _LIB_VERSION variable for setting the libm error handling 
mechanism.

-- 
Joseph S. Myers
joseph@codesourcery.com