Re: 32/64 bit non-portability

> amk <A.M.King@ukc.ac.uk> 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.


  nmm1@cus.cam.ac.uk (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
(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.

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