64 bit architectures and C/C++

Clive Feather clive at x.co.uk
Tue May 21 18:12:41 AEST 1991


In article <1991May18.011520.8330 at sq.sq.com> msb at sq.sq.com (Mark Brader) writes:
[>>> is msb, >> is myself]
>>> Suppose that the implementation
>>> defines long to be 64 bits; then, to force such a failure, the programmer
>>> would have to take some explicit action, like
>>>	assert (LONG_MAX >= 0777777777777777777777);
>> If you want the compilation to fail, then what's wrong with the
>> following ?
>>     #if LONG_MAX < 0xFFFFffffFFFFffff		/* wrong, actually */
>>     ??=error Long type not big enough for use.
>>     #endif

> I would take that to be "something like" my assert() example, and don't
> have a strong preference between one and the other.

True. The only advantage I claim for it is that it is a compile time
test, rather than a run-time test.

> But whichever of these the programmer uses, *it has to be coded explicitly*.
> My feeling is that enough of the 64-bit people [i.e. those worth $8 :-)]
> will carelessly omit to do so, once 64-bit machines [i.e. those worth $8!
> :-) :-)] become more common, as to create portability problems.  It will,
> I fear, be exactly the situation that we've already seen where there's
> much too much code around that assumes 32-bit ints.

But no-one suggests forcing ints to be 32 bits just to solve this
problem. In general, there is no sympathy for people who fail to code
for portability. Why should we make an exception for this one case. You
might equally well say that people used to 36-bit machines shouldn't
have to write code like:

    #if UINT_MAX >= 0x3FFFF
    typedef signed   int  native_int_like_type;
    #else
    typedef signed   long native_int_like_type;
    #else
    #if INT_MAX >= 0x1FFFF && INT_MIN < -0x20000
    typedef unsigned int  native_uint_like_type;
    #else
    typedef unsigned long native_uint_like_type;
    #else

if they want to continue to think in 18-bit ints.

> However, if one *is* going to amend it, it would be as well if the
> amended version retained the correct value of the constant.

Mea culpa.
-- 
Clive D.W. Feather     | IXI Limited         | If you lie to the compiler,
clive at x.co.uk          | 62-74 Burleigh St.  | it will get its revenge.
Phone: +44 223 462 131 | Cambridge   CB1 1OJ |   - Henry Spencer
(USA: 1 800 XDESK 57)  | United Kingdom      |



More information about the Comp.lang.c mailing list