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

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

On Fri, 7 Jul 2000, Martin v. Loewis wrote:

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

There are enough options in GCC to vary the ABI, or to adjust the sizes of
standard types (e.g. -mint64, -mlong64, -mlong32 on mips; -mint32, -mint16
on pdp11) that presuming that a single consistent ABI for each platform
can be agreed with the vendors seems unwise.  Given such options for
varying int and long - along with such other options as -fshort-wchar,
-funsigned-char - it seems likely that such options will be required in
future for varying <stdint.h> types.  (The mere existence of
-fshort-wchar, and WCHAR_MIN and WCHAR_MAX in <stdint.h>, means <stdint.h>
must depend somewhat on the options given to GCC.)

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

printf argument checking - see where c-common.c has

#define T_I     &integer_type_node
#define T_L     &long_integer_type_node
#define T_LL    &long_long_integer_type_node
...
#define T_V     &void_type_node
#define T_W     &wchar_type_node
#define T_ST    &sizetype

and the natural extension to cover %j would add intmax_type_node,
uintmax_type_node (which would be long_integer_type_node or
long_long_integer_type_node, etc., as appropriate).  Ideally the checking
might object to using long / long long directly instead of the appropriate
type, but this isn't really practical and the current size_t %z checking
[at present somewhat broken - I have an untested patch] doesn't do
this.  Some way of accessing this type is then needed for testing.  Note
that at present mis-use of long with int formats and vice versa is
detected - which points out both bugs on platforms where they are of
different sizes and problems where a non-ISO-C (e.g. POSIX) system type is
being using with printf without a cast.  So the size of the type is not
enough.

In addition, special types (which are not character types) are desirable
for int8_t and uint8_t so types of size 1 can be used while getting the
aliasing advantages of -fstrict-aliasing (char can alias anything, but
int8_t need not have that property).

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