This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 <> 
as you suggested in 
<> 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 

Joseph S. Myers

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]