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, Marek Polacek wrote:
> Also, more cleanups come to mind--what about e.g.:
>
> #ifdef __STDC__
> #include <stdlib.h>
> #endif
[...]
All __STDC__ conditionals should be removed - except in code for which
some project other than glibc is the master (e.g. much of what's in the
intl/ directory), in which case any removal should happen upstream of
glibc first and later get into glibc by an update from upstream. (As I
noted, intl/ is probably more worthwhile to update from upstream than the
GMP code - intl/ provides actual public interfaces to glibc, whereas GMP
code is only used for limited internal purposes.)
I have been removing small batches of __STDC__ conditionals at a time
because it's a lot easier for someone to look over a small patch, and spot
any mistakes therein, than a large patch doing everything at once.
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.)
> Oh, and one offtopic question: where does the __BOUNDED_POINTERS__ macro
> come from? Thanks,
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.
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)?
--
Joseph S. Myers
joseph@codesourcery.com