Defining predefined macros for whole translation unit, revisited

["Joseph S. Myers" <joseph at codesourcery dot com>]

C99 has standard macros __STDC_IEC_559__, __STDC_IEC_559_COMPLEX__ and 
__STDC_ISO_10646__ that are required to be constant throughout the 
translation unit (rather than, as at present, being defined in 
<features.h> so undefined before system headers are included).  C11, and 
various TRs and standards adding optional C (language and library) 
features, add further such macros that describe properties of the compiler 
and library together - or sometimes just library properties.

I previously proposed an approach of providing a <stdc-predef.h>, split 
out of <features.h>, with just these definitions, to be preincluded 
automatically by GCC if it exists (and included explicitly by <features.h> 
for use with older compilers).  The patch was posted in 
<http://sourceware.org/ml/libc-alpha/2009-04/msg00005.html> (and the GCC 
patch approved conditional on the glibc one) and 
<http://sourceware.org/bugzilla/show_bug.cgi?id=10110>; there was one 
objection on the grounds of complexity.  (I suggested this general 
approach, and other possible uses for it, on various previous occasions as 
well, e.g. <http://sourceware.org/ml/libc-alpha/2001-11/msg00011.html>.)

I still think this change is the best approach for implementing this 
standard requirement, and so would like to know what a wider range of 
people think of it.  (Presume that the patch would be updated and retested 
if the conclusion is that it is indeed the right approach.)  Note that 
from glibc's perspective it's just another internal header, of which there 
are a great many already; all the complexity is in GCC.  Reasons for this 
approach, rather than something involving GCC extracting values when 
configured, include:

* This approach also supports having independent implementations of 
various standard C library extensions - they can provide their own 
<stdc-predef.h> that does #include_next of the main one (and any number of 
extensions can be used together like that).  Compiler extraction of 
predefined values means the compiler needs to know about exactly what 
such libraries will be used when it is configured.  DFP people 
specifically have expressed an interest in this.

* GCC and glibc builds are too entangled as-is when bootstrapping cross 
tools to a system; cross builds of glibc and glibc-targetted tools are 
unnecessarily hard.  It would be desirable to reduce the entanglement and 
make it easier and faster to build such tools, without needing the 
multiple separate GCC builds interleaved with glibc configuration / 
headers install / full build and install that are presently needed.  To 
reduce the dependencies, it's desirable to avoid cases where information 
from the library headers is needed when configuring the compiler proper 
(and avoid where possible cases where such information needs providing 
manually to GCC's configure script).  Use of such information in building 
GCC's libraries isn't a problem except where it affects the use of those 
libraries with newer glibc - a case which makes extraction of predefines 
less than ideal.  (We should reduce the opportunities for things to go 
wrong when people build things - including when they update only one 
component without updating others.)

* It's important for GNU packages and projects to work well together.  In 
cases like this it means working out what is best for the system as a 
whole, rather than what's "best" or simplest for one package in isolation.  
It can mean separate packages having features to work with each other 
(with, as noted in the previous point, clean and simple interfaces rather 
than undue entanglement).  One package doing entirely its own thing and 
telling other packages to adapt to that is not a good way of doing things.  
In this case I think the correct place for *most* of the work is in GCC - 
but with glibc doing its part of putting a few definitions in this 
separate header.

-- 
Joseph S. Myers
joseph@codesourcery.com