This is the mail archive of the libc-alpha@sourceware.org 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


> See the recent discussion starting at 
> <http://sourceware.org/ml/libc-alpha/2012-01/msg00003.html>: a GCC feature 
> that was unmaintained and removed many years ago.  I think the development 
> mainline of the repositories should be for currently useful code; having a 
> version control system means you have history of removed code available 
> should it become useful in future, so "in case a similar feature becomes 
> available" is not what I consider a good reason to keep code in mainline 
> and I think bug 13550 should not have been closed WONTFIX.

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.)

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.


Thanks,
Roland


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