This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Remove __STDC__ conditionals from installed headers
On Fri, 27 Jan 2012, Roland McGrath wrote:
> I think it's a generally sound principle. But I really don't think there
> is ever much of a hurry to remove cruft, even if it's been useless for a
> long time. If anyone balks for any reason, then it just doesn't hurt to
> leave well enough alone for a while longer. (And, of course, there is
> always a danger when touching any code--especially mechanical changes made
> en masse--of accidental breakage that isn't noticed immediately.)
I've created the wiki page <http://sourceware.org/glibc/wiki/Deprecation>
as you suggested in
<http://sourceware.org/ml/libc-alpha/2012-01/msg00007.html> to list
features proposed for removal, listing bounded pointers, support for
pre-2.6 Linux kernels and (in ports) the am33 and cris ports as candidates
for removal after 2.16 in the absence of more concrete uses for the code
appearing. (I used the wiki where previously I suggested Bugzilla, since
(a) it's useful to describe the general principle somewhere and (b)
candidates closed as WONTFIX for not removing right now should still be
tracked for potential later removal.)
> The BP macros in assembly code might be a bit of a special case. If such a
> feature were reintroduced in the future, it would require a lot of careful
> touching of assembly code, which is always difficult. The existing macros
> and their use do no harm, and they mark the assembly code where such
> attention is relevant. That said, I'm sure there is newer assembly code by
> now that lacks them and so a new feature along those lines would
> necessitate pretty careful attention to all the existing assembly code.
> So I don't think it matters much one way or the other.
If the code isn't touched for other changes, the diff of the commit that
removed the support could always be applied in reverse; if the code is
touched for other changes, then the bounded pointers code may have got in
the way or distracted someone, and the removal commit is still available
for reference. (In fact we know it distracted someone - that's how this
discussion got started. There's plenty of essential complexity in glibc
that will always make some aspects quite tricky to understand, but
avoiding complexity that isn't actually being used is one way to make
things easier to understand and help attract people to contributing
changes.)
--
Joseph S. Myers
joseph@codesourcery.com