|32/64 bit non-portability A.M.King@ukc.ac.uk (2002-05-17)|
|Re: 32/64 bit non-portability email@example.com (2002-05-23)|
|Re: 32/64 bit non-portability derek@NOSPAMknosof.co.uk (dmjones) (2002-05-23)|
|Re: 32/64 bit non-portability firstname.lastname@example.org (Christian Bau) (2002-05-27)|
|Re: 32/64 bit non-portability email@example.com (Nick Maclaren) (2002-05-27)|
|From:||Christian Bau <firstname.lastname@example.org>|
|Date:||27 May 2002 01:17:33 -0400|
|Posted-Date:||27 May 2002 01:17:33 EDT|
> 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.
email@example.com (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.
Return to the
Search the comp.compilers archives again.