Re: 32/64 bit non-portability

Christian Bau <christian.bau@freeserve.co.uk> wrote:
>I think in the desktop computer world you will find quite a lot of
>code that assumes long == 32 bit, and a compiler might include some
>heuristics to find warning signs.
>
>Obviously, any cast from pointer to int/long if int/long is not large
>enough to hold that pointer value is a problem (if you keep long == 32
>bit, long long == pointer == 64 bit). Bitwise "and" between unsigned
>long and a constant like 0xfffffffe is a bad sign if long > 32 bit.
>Operations that swap bits around in an unsigned long, like (x << 16) |
>(x >> 16) if long > 32 bits. Warnings in these cases would be very
>much appreciated. And any use of the constant 4 as an argument in
>memset, memcpy, memcmp, fread, fwrite where you would expect sizeof
>(long).
>
>Of course, people who are used to other kinds of machines won't make
>these kinds of mistakes. Well-written programs won't benefit much, but
>sadly many programs will.


Yes, I agree, but didn't make myself clear. A looked at a couple of
dozen 'typical' desktop programs in some detail, and there were
relatively few dependencies on the exact size of long, but a great
many (and much more serious ones) on size_t <= unsigned long, which is
what breaks in C99.


The main cause of 32-bit assumptions was using Internet addresses, and
the second one was in constructions like you mention. ANY
18-character hexadecimal constant starting with 0x8-0xf and used in an
operation involving long or unsigned long is worth flagging. As is
any memory operation with a length that is not a multiple of the size
of the address types (using sizeof!)


But, once I had excluded that sort of thing, I found very little.
Clean programs don't use the same long variable for an Internet
address and calculation in the same function without a clear
indication of which value is being used. And my experience in
compiling programs under our DEFAULT configuration of 64-bit IRIX
confirms this.


So what I meant was that example programs will add little. There are
a few simple checks that will pick up almost everything that you will
see in clean codes, and few programs will trigger these in more than a
few places. And the programs that many much more serious 32-bit
assumptions are likely to be so ghastly that they will trigger any
correctness or portability test, thoughout.




Regards,
Nick Maclaren,
University of Cambridge Computing Service,
New Museums Site, Pembroke Street, Cambridge CB2 3QH, England.
Email: nmm1@cam.ac.uk
Tel.: +44 1223 334761 Fax: +44 1223 334679

Return to the comp.compilers page.
Search the comp.compilers archives again.