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

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

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

I would not take existance of these options as a proof that they are
actually used, or that the ABI of operating systems is normally
underspecified. On what MIPS operating system would you find all these
variations simultaneously?

I'd rather expect that these options exist for certain freestanding
environments, to ease porting so that adding a GCC target would not be
necessary; instead, the command line option could be used. In these
cases, <stdint.h> would be written by the same person that also
defines the set of command line options that must be used.

For hosted environments, it seems reasonable to expect a single
consistent ABI. Delegating ABI decisions to the compiler user would be
unwise; she normally couldn't care less.

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

No. It rather means that -fshort-wchar is not supported in certain
hosted environments - and it should not be.

> and the natural extension to cover %j would add intmax_type_node,
> uintmax_type_node 

Yes, that would be the natural extension. I don't see the need for
magic predefined typedefs, though - just the need for additional
global tree nodes.

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

For it not to have this property, it would have to be 

typedef signed short int8_t;

and short would have to be a type of exactly 8 bits, right? Well, this
would be non-conforming, as 5.2.4.2.1 requires short to have at least
16 bits. As a result, int8_t must be the same as signed char (or
potentially as char). Therefore, int8_t* can legally alias with any
other pointer in C99.

Regards,
Martin