Builtin types, <limits.h>, <stdint.h> etc.

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

As <stdint.h> is a header required for freestanding implementations in
C99, GCC will need to have its own at some point.  (Glibc already has one,
with which compatibility / interoperation is highly desirable.)  GCC also
needs a builtin notion of intmax_t and uintmax_t to do printf format
checking for %jd, %ju formats.  So I've been looking at the existing
handling of such builtin types.

(a) It seems from the source that, on targets which don't have 8-bit char,
16-bit short, 32-bit int (or on which the sizes of the types can be varied
by -m options), the generated <limits.h> is incorrect.  Is this the case?

(b) The <stdint.h> types may need to be compatible with those chosen by
vendors.  For intmax_t, this may affect the printf ABI.  For the _fast
types, GCC and a vendor might quite plausibly choose different lengths.  
For the other types, choice of int versus long might differ (meaning that
<inttypes.h> would need to be fixincluded).  So in general it may be
needed to change these types at runtime.

(c) Such types could be implemented by defining __builtin_intmax_t and
similar, or __INTMAX_TYPE__ (similar to __SIZE_TYPE__).  I'd like to
implement intmax_t in GCC soon for the printf support (choosing a type
compatible with glibc - long if the same size as long long, else long
long); which would be more appropriate for such initial implementation?

(d) The variability of the types could cause problems for using predefined
macros __INTMAX_TYPE__ in that many such definitions would need to be
passed to cpp on the command line.  However, if cpplib will soon be
integrated in the compiler, this should become less important.

(e) Proper definition of the limits in <stdint.h> (and indeed those in
<limits.h>) requires information about the types to be known to the
preprocessor, since the _MIN and _MAX values must be integer constant
expressions, of the right type and suitable for use in #if.  While in many
cases the types are fixed and can be hardcoded in the file, is there any
better general way than having the compiler predefine many macros needed
for this header?  Would it be appropriate to pregenerate for all fixed
types, and then only predefine in the compiler for those types that can
vary at runtime; or to predefine the macros for all non-variable types in
the preprocessor?

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