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

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