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.
