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: 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: Tue, 11 Feb 2014 15:24:51 -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> <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> <Pine dot LNX dot 4 dot 64 dot 1402112256080 dot 11759 at digraph dot polyomino dot org dot uk>
> 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.
OK, that sounds reasonable.
> 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.)
I don't have a suggestion about this. I was thinking of starting with the
interfaces that it's pretty easy to be sure that nobody is using, such as
sigvec. (That is, if anybody is using them, we don't have much sympathy.)
For anything we are less thoroughly sure about, we should probably follow a
slower multi-step deprecation procedure: add header attributes so uses get
warnings, and announce in NEWS the plan to remove; next release cycle,
actually remove it (or delay or reconsider based on user feedback).
> 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).
Let's defer contemplation of this until we hit the first case where an
existing test uses an interface we want to deprecate.
> 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.
Sounds reasonable, if there are no currentish standards that still
incorporate those parts of the old SVID spec.