This is the mail archive of the
mailing list for the glibc project.
Re: Remove __STDC__ conditionals from installed headers
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.
> 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.