Re: Remove __STDC__ conditionals from installed headers

[Marek Polacek <polacek at redhat dot com>]

On 01/27/2012 12:27 PM, Joseph S. Myers wrote:
> And, yes, removal of macros such PARAMS, _G_ARGS, _G_HAVE_SYS_CDEFS makes 
> sense as well.  (Although in an installed header, I don't think macros in 
> _G_config.h should be considered part of the public API to glibc; it's 
> just internal configuration for libio, which nowadays is only part of 
> glibc and hasn't been used in libstdc++ for many years.)  Similarly, 
> __ELF__ conditionals can also be removed.  In all cases, the same 
> principle applies about avoiding unnecessary local changes to any code for 
> which glibc is not the master source.  (I probably won't be doing any of 
> these followup cleanups until I've finished the __STDC__ cleanups, so they 
> may be a good place to clean things up without conflicting with my 
> __STDC__ changes.)

Thanks Joseph.  I won't touch the __STDC__ stuff to not interfere with you.
I'll do the PARAMS first, then the __ELF__ cruft.  And then we can step
up to those other things.
It seems to me that the code which glibc is not the master resides in
directories intl/, timezone/, resolv/, and hesiod/.

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

Agreed.

> We might sometimes keep some not-currently-usable code for a bit in the 
> hope of finding a maintainer - or explicitly deprecate it and make a last 
> call for a maintainer (as GCC and GDB do with target deprecations), then 
> wait a bit before removing it - to avoid needless churn with code being 
> removed and added back soon afterwards.  But there comes a point when it 
> is clearly time to remove the old and unused code, and I think that point 
> came long ago for the bounded pointers code.

This all sounds sensible to me.

> What does the glibc community in general think about this - both the 
> general principle of how we use the repository (which should probably go 
> on the wiki e.g. <http://sourceware.org/glibc/wiki/GlibcGit> if we get 
> rough consensus) and the specific point of whether we should remove the 
> bitrotten bounded pointers code (where both Roland and I have expressed 
> support for the removal, while Ulrich has opposed it)?

FWIW, I'm all for removing it--looks like it would make it possible
to clean up quite a lot of asm code and headers.

	Marek