This is the mail archive of the
mailing list for the GCC project.
Re: Builtin types, <limits.h>, <stdint.h> etc.
- To: jsm28 at cam dot ac dot uk
- Subject: Re: Builtin types, <limits.h>, <stdint.h> etc.
- From: "Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>
- Date: Sat, 8 Jul 2000 19:07:09 +0200
- CC: gcc at gcc dot gnu dot org, gavin at cygnus dot com
- References: <Pine.SOL.email@example.com>
> I would want __builtin_intmax_t and __builtin_uintmax_t so that
> meaningful testcases for the printf format checking support could be
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
(126.96.36.199) 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
Unless this has been studied sufficiently, I'd vote against these