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

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> (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.  

No, that won't work. If the vendor puts one of these types as a field
in a structure, or if some function has an array of them as argument,
then gcc-compiled and vendor-cc-compiled files would not interoperate.

As a result, clearly the ABI of each platform must define what these
types are. GCC could pioneer that part ABI on platforms where the
vendors haven't already specified those headers, but I'd rather prefer
if that was done in cooperation with the system vendors.

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

I don't know what "runtime" is in this context; I think the choices
for the inttypes must be made during gcc configuration, as part of
selecting the target.

> (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?

What exactly do you want to implement? printf? Or the printf argument
checking? For that, you wouldn't need any predefined define or builtin
typedef. Instead, just check whether the size of the argument is
right, with a target-depending macro, e.g. INTMAX_SIZE. You could also
assume reasonable defaults, e.g. that intmax_t will be the same as
long long on most platforms.

> (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.

I still don't see the need for a #define. <stdint.h> can be generated
when configuring gcc.

Regards,
Martin