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

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

[Joseph S. Myers]

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

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

[Martin v. Loewis]

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

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

[Joseph S. Myers]

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

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

[Martin v. Loewis]

> 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

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

[Joseph S. Myers]

On Sat, 8 Jul 2000, Martin v. Loewis wrote:

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

If a copy of GCC can be compiled on which it might be meaningful to use
different combinations of the options, I would say it is the job of GCC to
provide the conforming freestanding implementation (possibly by providing
multiple versions of <stdint.h> for each environment supported, which I
suppose would be somewhat like multilibs).

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

I would want __builtin_intmax_t and __builtin_uintmax_t so that meaningful
testcases for the printf format checking support could be written.  There
are already magic types in GCC with pretty specialised uses (e.g. the G77
types in the C compiler).

What is the purpose of the __builtin_size_t typedef?  (CC:ed to Gavin
Romig-Koch who added it last December.)  It doesn't seem to be used
anywhere in the GCC source tree, and since C89 requires that size_t be one
of the standard C89 types (Clive Feather's DR#067), using it for the
externally visible size_t in <stddef.h> would require great care not to
break C89 conformance.

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

The <stdint.h> types may be extended integer types.  I'm saying that it
would be advantageous for int8_t to be one.  (This being a change from C89
which did not have any concept of extended integer types with defined
behaviour in the standard, and did not allow types such as size_t to be
extended types.)

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

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

[Martin v. Loewis]

> I would want __builtin_intmax_t and __builtin_uintmax_t so that
> meaningful testcases for the printf format checking support could be
> written.

If that is the only rationale, then I still can't follow. What is the
target which does not have a well-known compile-time-determinable
intmax_t, so that you need to decide on this type at run-time?

Or, if it is indeed possible to always know at compiler configuration
time, why is it that you need this type?

> The <stdint.h> types may be extended integer types.  I'm saying that it
> would be advantageous for int8_t to be one.  (This being a change from C89
> which did not have any concept of extended integer types with defined
> behaviour in the standard, and did not allow types such as size_t to be
> extended types.)

I see; I didn't know that C99 explicitly allows for additional
integral types, and that <stdint.h> is also meant to give standard
names to these types.

However, I would seriously caution not to introduce additional
integral types into gcc, as they would introduce many new problems.
Let's say we add __byte, which is unsigned 8 bit. What is the rank
(6.3.1.1) of that type? Less then char, apparently. Would that still
meet the expectations of the users?

Also, if such a type would be added, should it be added to C++ as
well? If so, how would it affect overloading, and subsequently
mangling?

Unless this has been studied sufficiently, I'd vote against these
extended types.

Regards,
Martin

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

[Joseph S. Myers]

On Sat, 8 Jul 2000, Martin v. Loewis wrote:

> If that is the only rationale, then I still can't follow. What is the
> target which does not have a well-known compile-time-determinable
> intmax_t, so that you need to decide on this type at run-time?
> 
> Or, if it is indeed possible to always know at compiler configuration
> time, why is it that you need this type?

I'd rather avoid fragile conditionals along the lines of

	#if defined (__alpha__) || defined (__ia64__) || defined (__sparcv9)
	typedef long intmax_t
	#else
	typedef long long intmax_t
	#endif

	void foo (intmax_t t) { printf("%jd\n", t); }

when the compiler can readily communicate its notion of intmax_t to the
program.

(Printf checking for %j is easy to implement and useful now on existing
glibc 2.1 systems with support for %j (and probably other systems),
whereas it seems to me that <stdint.h> in GCC is more difficult.  OTOH,
one might feel <stdint.h> should be implemented in GCC first, initially on
a mostly correct basis (e.g. following glibc's implementation, which is
fine for the systems glibc supports), which would however be broken on the
odder architectures such as c4x, so it could be used to indicate GCC's
notion of intmax_t - as long as <stdint.h> stays in sync with GCC's
internal type - and later fixed to be correct on all systems.)

(Looking at the headers on a Solaris 2.6 box - based on an earlier
standard proposal with only <inttypes.h> and no separate <stdint.h> - I
see an intmax_t varying depending on compilation options.  Whether this
arises on any system with which compatibility is needed, I don't know.

/usr/include/sys/int_types.h:

	#if defined(_LP64) || (__STDC__ - 0 == 0 && !defined(_NO_LONGLONG))
	typedef int64_t                 intmax_t;
	typedef uint64_t                uintmax_t;
	#else
	typedef int32_t                 intmax_t;
	typedef uint32_t                uintmax_t;
	#endif

Using cc will get the 64-bit definitions, cc -Xc the 32-bit
ones.  However, that header does say "Use at your own risk.".)

> However, I would seriously caution not to introduce additional
> integral types into gcc, as they would introduce many new problems.
> Let's say we add __byte, which is unsigned 8 bit. What is the rank
> (6.3.1.1) of that type? Less then char, apparently. Would that still
> meet the expectations of the users?

I think the view that there is demand for such an int8_t is evidenced by

http://gcc.gnu.org/ml/gcc/2000-05/msg01106.html

(which is probably why having such a type came to mind as a possibility
for a GCC implementation of <stdint.h>).

For types of rank less than that of int and unsigned int, I don't think
the exact rank is particularly significant.

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

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

[Geoff Keating]

"Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:

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

As an example, on AIX/ppc the size of 'long' and pointers can be 32
bits or 64 bits, controlled by a compiler switch, and the header files
and libraries adjust themselves.

The significance of this is that intptr_t needs to change depending on
the setting of this flag.

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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

[Martin v. Loewis]

> As an example, on AIX/ppc the size of 'long' and pointers can be 32
> bits or 64 bits, controlled by a compiler switch, and the header files
> and libraries adjust themselves.
> 
> The significance of this is that intptr_t needs to change depending on
> the setting of this flag.

I see. I assume that the adjustment of the headers is done with
preprocessor defines. Would it be better to adjust <stdint.h> by the
same preprocessor defines, or by compiler built-in typedefs?

Regards,
Martin

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

[Martin v. Loewis]

> > Or, if it is indeed possible to always know at compiler configuration
> > time, why is it that you need this type?
> 
> I'd rather avoid fragile conditionals along the lines of
> 
> 	#if defined (__alpha__) || defined (__ia64__) || defined (__sparcv9)

I'm not talking about conditionals of that kind. Instead, it should be
possible to

a) either take the vendor-provided stdint.h, if any, or
b) generate one upon installation, e.g. by

   if (LONG_TYPE_SIZE == INTMAX_TYPE_SIZE)
     printf("typedef long intmax_t;\n");
   else
     printf("typedef long long intmax_t;\n");


> when the compiler can readily communicate its notion of intmax_t to the
> program.

It can indeed. All that is required is that the configuration
information of the header file matches the one in config/. There are
many ways to achieve this; the one you propose gives trouble to the
users, as they can't easily tell what type is actually chosen.

> OTOH, one might feel <stdint.h> should be implemented in GCC first,
> initially on a mostly correct basis (e.g. following glibc's
> implementation, which is fine for the systems glibc supports), which
> would however be broken on the odder architectures such as c4x, so
> it could be used to indicate GCC's notion of intmax_t - as long as
> <stdint.h> stays in sync with GCC's internal type - and later fixed
> to be correct on all systems.)

I'm not sure which one is better: providing no <stdint.h> at all, or
providing one that needs to be changed later when target experts
conclude that the original one was incorrect.

> /usr/include/sys/int_types.h:
> 
> 	#if defined(_LP64) || (__STDC__ - 0 == 0 && !defined(_NO_LONGLONG))
> 	typedef int64_t                 intmax_t;
> 	typedef uint64_t                uintmax_t;
> 	#else
> 	typedef int32_t                 intmax_t;
> 	typedef uint32_t                uintmax_t;
> 	#endif
> 
> Using cc will get the 64-bit definitions, cc -Xc the 32-bit
> ones.  However, that header does say "Use at your own risk.".)

Well, in strict mode, they just can't offer a 64bit type, at least not
on Sparc v8; in v9 compilations (with _LP64), they have always a 64
bit type. I'd say this is a bug; any data structure containing
intmax_t will change in layout depending on the compiler option. They
simply haven't thought about that - you cannot change the size of
these types from compilation to compilation like that.

> I think the view that there is demand for such an int8_t is evidenced by
> 
> http://gcc.gnu.org/ml/gcc/2000-05/msg01106.html
> 
> (which is probably why having such a type came to mind as a possibility
> for a GCC implementation of <stdint.h>).

I wasn't questioning the rationale for having such a type. I was
arguing that introducing it will lead to problems.

Regards,
Martin

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

[Geoff Keating]

> Date: Sat, 8 Jul 2000 23:56:01 +0200
> From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>

> > As an example, on AIX/ppc the size of 'long' and pointers can be 32
> > bits or 64 bits, controlled by a compiler switch, and the header files
> > and libraries adjust themselves.
> > 
> > The significance of this is that intptr_t needs to change depending on
> > the setting of this flag.
> 
> I see. I assume that the adjustment of the headers is done with
> preprocessor defines. Would it be better to adjust <stdint.h> by the
> same preprocessor defines, or by compiler built-in typedefs?

Actually, the adjustment for LONG_MAX is presently not done at all (I
just found and fixed that problem) but it's going to be done by having
the specs file define __LONG_MAX__ in the preprocessor.  

An alternative, which I rejected, was to change the header file
gcc/glimits.h to fix the existing condition:

#if defined (__alpha__) || (defined (_ARCH_PPC) && defined (__64BIT__)) || (defined (__sparc__) && defined(__arch64__)) || defined (__sparcv9)

but clearly this is not a scalable solution.  It's also error-prone,
as demonstrated by the bug (the bug is that _ARCH_PPC is not defined
in common or POWER modes).

-- 
- Geoffrey Keating <geoffk@cygnus.com>

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

[Andreas Schwab]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1247 bytes --]

Geoff Keating <geoffk@cygnus.com> writes:

|> "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de> writes:
|> 
|> > > 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.
|> ...
|> > 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.
|> 
|> As an example, on AIX/ppc the size of 'long' and pointers can be 32
|> bits or 64 bits, controlled by a compiler switch, and the header files
|> and libraries adjust themselves.
|> 
|> The significance of this is that intptr_t needs to change depending on
|> the setting of this flag.

Strictly speeking, it doesn't, since intptr_t does not need to be exact,
i.e., it can be bigger than necessary.

Andreas.

-- 
Andreas Schwab                                  "And now for something
SuSE Labs                                        completely different."
Andreas.Schwab@suse.de
SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg