Re: how to detect int64?

[Paul Eggert]

On 07/19/10 17:24, Jay K wrote:

> Wow.
> So..it sounds to me like..these systems would have a 31 bit unsigned int
> and a 63 bit unsigned long?

I believe the Unisys machine has a 36-bit signed int and
a 35-bit unsigned int, with longs being about twice as long.
(I haven't verified this.)

> And there are no unsigned integers of exactly 32 or 64 bits?

There's no requirement for them in either C or POSIX, no.
Perhaps they have them, but if they do, they're slow or
space-inefficient or both.

> Autoconf would correctly fail if code asked for them?

Yes, that's the idea.

> And uintptr_t might not exist?

That's allowed, yes.

> (On the no-autoconf angle, I have long assumed sizeof(size_t) ==
> sizeof(void*), however I recently found an exception.

Yes, exceptions to that are not that uncommon.  Even some smaller x86
platforms have done that, with 32-bit pointer and 16-bit size_t.

> So autoconf's job is to find integer that can hold exactly 32 or 64
> bits, no more, no less.

For uint64_t, yes.  Alternative types such as uint64fast_t need
not be exactly 64 bits.

> You know -- I'd hope that there is at least an ANSI C89  limits.h, and
> that implementations
> that have a 63 or 64 bit integer would think to add something for it.

That stuff didn't get added until C99.  And some compiler-writers haven't
caught up entirely.  It's in stdint.h and inttypes.h.

> We have a somewhat significant
> "statically configured" system,
> it knows how to compile C, assemble (!), make static libs and shared
> libs on a fixed set of systems, is slightly
> #ifdefed. Interix, Solaris, Darwin, Linux, Net/Open/FreeBSD, OSF1 4 and
> 5, Cygwin, MinGW, NT, HP-UX, maybe future VMS, Irix, AIX.

Yup, I was in the same boat, back around 1992.  Autoconf is better.
In many ways it's awful, but still, it's better than that.