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

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

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