GCC's headers

["Joseph S. Myers" <jsm28 at cam dot ac dot uk>]

This doesn't seem to have been clearly stated in the discussion of what
headers GCC should install:

Several of the headers installed by GCC are provided because they are
required to be provided by conforming freestanding implementations, which
GCC claims to be (albeit without a proper conformance document - defining
all implementation-defined characteristics and all extensions - short of
the complete source distribution).  GCC might choose to use the system
headers instead of its own if the system headers are conforming, or to use
fixincluded versions of them, but it is GCC's responsibility to ensure
that conforming versions of these headers are available, and to provide
them where necessary to systems without the full library.

1989/1990: <float.h> <limits.h> <stdarg.h> <stddef.h>
1994/1995: <iso646.h>
1999: <stdbool.h> <stdint.h>

The only cases where using the system header is likely to be useful are
probably <limits.h>, <stddef.h>, <stdint.h>.  <stdarg.h> is strongly
GCC-dependent; <iso646.h> seems unlikely to cause problems, and nor should
a conforming <stdbool.h> (as opposed to the current one based on an old
draft).  <float.h> isn't complete in GCC for C99, but it also describes
compiler/architecture characteristics rather than library ones.  The
problems with <limits.h> <stddef.h> <stdint.h> are library interaction
ones being discussed.  GCC's <limits.h> seems presently to be broken for
odd architectures (e.g. c4x), no-one seems willing to touch <stddef.h> [to
quote <URL:http://gcc.gnu.org/ml/gcc-patches/1999-02n/msg00453.html>, "I'd
like to consider this [rewritten <stddef.h>] for inclusion after egcs-1.2
branches.", but <stddef.h> still defines wint_t and is a mess], and GCC
doesn't have a <stdint.h> yet; one would be plausibly doable for embedded
systems, but interaction with system headers when provided to systems
which don't have one but do have <inttypes.h> from old drafts would be a
serious pain (and if using the system <stdint.h> should still fix bugs in
it, e.g. glibc's one gets the type of WCHAR_MIN and WCHAR_MAX wrong on x86
Linux where __WCHAR_TYPE__ is long int).

-- 
Joseph S. Myers
jsm28@cam.ac.uk