Re: Python compiler warns about use of 0xffffffff

> As reported online at http://bugs.debian.org/358023 , BitPim uses the
> hex literal 0xFFFFFFFF in a couple of files, triggering compile-time
> FutureWarnings on 32-bit systems:

The Python interpretter is actually wrong about these and there is
nothing we can do to fix them.  The problem is that up to Python 2.3
ints (ie 32 bit processor type) and long (more than 32 bits python
type) are seperate entities.  In Python 2.4 they are unified with
Python automatically converting as appropriate without losing
precision.

The math that is done to produce the numbers being compared is
done in the default integer type.  These comparisons need to
happen in the same type.  ie if Python does make numbers
negative because the top bit is set then it needs to happen
to both.  I guess I could cause all the math and all constants
in longs, but that is a rather silly way to get get rid of
warnings.

That said the code does attempt to turn off warnings when
run optimized.  See src/bp.py.  It also makes stdout and
stderr be dummies that don't do anything.  So there should
be no output at all.  (This behaviour can be changed by
specifying 'debug' as a command line argument).

Roger


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642