[BitPim-devel] Python compiler warns about use of 0xffffffff

[Aaron M. Ucko]

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:

/usr/share/bitpim/com_lgpm225.py:1065: FutureWarning: hex/oct constants

sys.maxint will return positive values in Python 2.4 and up

serial1=helper.getserial(entry.get('serials', []), self.serialsname,
data['uniqueserial'], 'serial1', 0xFFFFFFFF)
/usr/share/bitpim/com_sanyo.py:976: FutureWarning: hex/oct constants >
sys.maxint will return positive values in Python 2.4 and up
if res.entry.alarm==0xffffffff:

(I don't see such warnings on the x86_64 box I use for development,
where sys.maxint seems to be 2^63 - 1 and 0xFFFFFFFF is therefore
already positive.)

Could somebody please tweak the code to avoid such warnings?

Thanks!

[Roger Binns]

Post by Aaron M. Ucko
As reported online at http://bugs.debian.org/358023 , BitPim uses the
hex literal 0xFFFFFFFF in a couple of files, triggering compile-time

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

[Aaron M. Ucko]

Post by Roger Binns
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.

It looks like com_lgpm225.py simply needs an out-of-range value, for
which -1 (the current effective value on 32-bit systems AIUI) or
sys.maxint would work just as well -- or am I missing something? As
for com_sanyo.py, it's not clear to me whether the value should be -1
across the board or only on 32-bit systems.

Post by Roger Binns
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).

The warnings come from compileall.py, which runs on installation per
Debian's Python policy. I should be able to arrange to run that with
-Wignore, though.

Thanks for the explanation.

[Roger Binns]

Post by Aaron M. Ucko
It looks like com_lgpm225.py simply needs an out-of-range value, for
which -1 (the current effective value on 32-bit systems AIUI) or
sys.maxint would work just as well -- or am I missing something?

Yes you are. As I explained in my previous mail, the field that
it is comparing against is generated using some math elsewhere
(in particular a piece of code that takes bytes off the cable).
Whichever way Python decides decides to mutilate that (conversion
to long, conversion to signed) is exactly what it will do to
the constant value in the expression. In Python 2.4 it will
convert both to longs and the numbers will remain positive.
In Python 2.3 it may keep them as positive or make them negative,
but it will do the same thing to both.

Post by Aaron M. Ucko
for com_sanyo.py, it's not clear to me whether the value should be -1

It should never be -1. This is an unsigned number.

Post by Aaron M. Ucko
The warnings come from compileall.py, which runs on installation per
Debian's Python policy. I should be able to arrange to run that with
-Wignore, though.

That will work. This is one of those cases where the warnings are
wrong.

Roger