bug-autoconf
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: how to detect int64?


From: Jay K
Subject: RE: how to detect int64?
Date: Tue, 20 Jul 2010 00:24:42 +0000

 > This algorithm doesn't work on machines with padding bits,
 > that is, unused bits in the representation. It's possible, for example
 > for CHAR_BIT to be 8, sizeof (unsigned int) to be 4, but UINT_MAX
 > is 2**31 - 1 (not 2**62 - 1), because the hardware simply doesn't support
 > unsigned arithmetic and unsigned arithmetic is simulated with nonnegative
 > signed values, i.e., with a leading padding bit of zero.
 > 
 > This is not usually a practical problem, but it can occur on machines
 > that do not use two's-complement arithmetic. Such machines include
 > the Unisys ClearPath architecture, and possibly some DSPs. They're
 > not usually the target of autoconf apps but if they're easy to support
 > we might as well do it.
 
 
Wow.
So..it sounds to me like..these systems would have a 31 bit unsigned int and a 
63 bit unsigned long?
In order for unsigned long to be at least 32 bits?
And there are no unsigned integers of exactly 32 or 64 bits?
Autoconf would correctly fail if code asked for them?
And uintptr_t might not exist?
(On the no-autoconf angle, I have long assumed sizeof(size_t) == sizeof(void*), 
however I recently found an exception.
I do #include stddef.h and:
/* WORD_T/INTEGER are always exactly the same size as a pointer.
 * VMS sometimes has 32bit size_t/ptrdiff_t but 64bit pointers.
 */
#if __INITIAL_POINTER_SIZE == 64
typedef __int64 INTEGER;
typedef unsigned __int64 WORD_T;
#else
typedef ptrdiff_t INTEGER;
typedef size_t WORD_T;
#endif
)
 
 
So autoconf's job is to find integer that can hold exactly 32 or 64 bits, no 
more, no less.
Making sure it can hold the "value", not is of the right "size".
 

 
> > 2) #include <limits.h>, compare UNSIGNED_FOO_MAX for equality to 255, 
> > 65535, 4GB, etc.?
> > Before attempting to check for equal with the maximum 64bit number, since
> > preprocessor might reject such a large number you would:
> > See if long long exists, if so, ok.
> 
> limits.h might be missing the relevant UNSIGNED_FOO_MAX value.
> This sort of problem is all too common, unfortunately.
 
 
Wow again.
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. I have 
found a fair number
of different names for it, granted, like at least 3.
 
 
[tangent]
I'm going to stick with my "simple" approach for now since I'm not using 
autoconf, but I might
adopt autoconf and libtool soon. 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.
I could use a better cross story for e.g. iPhone, Android, and I get weary of 
doing this work, and suspect,
while we do a pretty good job across a pretty good selection of systems, 
autoconf+libtool would do significantly better and
we could get out of the business.
 
 
 
Thanks,
 - Jay                                    

reply via email to

[Prev in Thread] Current Thread [Next in Thread]