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

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

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