This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove _BSD_SOURCE and _SVID_SOURCE
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 11 Feb 2014 23:14:20 +0000
- 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> <20131216225338 dot 6FA7E7442E at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1312172307580 dot 3620 at digraph dot polyomino dot org dot uk> <20131220211322 dot F039874435 at topped-with-meat dot com> <Pine dot LNX dot 4 dot 64 dot 1402072338170 dot 12232 at digraph dot polyomino dot org dot uk> <20140211180457 dot 8963374448 at topped-with-meat dot com>
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