Re: 32/64 bit non-portability

Christian Bau <>
27 May 2002 01:17:33 -0400

          From comp.compilers

Related articles
32/64 bit non-portability (2002-05-17)
Re: 32/64 bit non-portability (2002-05-23)
Re: 32/64 bit non-portability (dmjones) (2002-05-23)
Re: 32/64 bit non-portability (Christian Bau) (2002-05-27)
Re: 32/64 bit non-portability (Nick Maclaren) (2002-05-27)
| List of all articles for this month |

From: Christian Bau <>
Newsgroups: comp.compilers
Date: 27 May 2002 01:17:33 -0400
Organization: Compilers Central
References: 02-05-085 02-05-097
Keywords: architecture, practice
Posted-Date: 27 May 2002 01:17:33 EDT

> amk <> wrote:
> >We are interested in building tools that aid in porting C code from 32
> >bit to 64 bit machines. Rather Than Constructing Our Own Examples, we
> >are keen to collect a series of problematic programs (or fragments of
> >non-portable programs) for the purposes of testing. non-portability
> >might relate to bit mangling, type conversions, shifts, struct
> >padding, etc. (Nick Maclaren) wrote:
> I doubt that you do! Pretty well any clean program just works, and
> 90% of them need few and localised changes. Spotting the usual
> potential problem areas is usually enough, though don't forget the
> interesting trap that long->double conversion is no longer precise.
> When C99 was changed to be incompatible with C89, it was claimed that
> a lot of programs relied on 32-bit longs. Well, I have seen very few
> - and the few I have seen were SO disgusting that they were almost
> useless as test examples. A program where there are more serious
> breaches of standard and non-portabilities than lines doesn't make a
> good test.

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

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.

Post a followup to this message

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