This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Builtin types, <limits.h>, <stdint.h> etc.
- To: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Subject: Re: Builtin types, <limits.h>, <stdint.h> etc.
- From: "Joseph S. Myers" <jsm28 at cam dot ac dot uk>
- Date: Fri, 7 Jul 2000 23:35:41 +0100 (BST)
- cc: gcc at gcc dot gnu dot org
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