[Python-Dev] 32-bit values (was RE: [Python-checkins] python/dist/src/Lib/test test_zlib.py,1.18,1.19)

[Tim Peters]

[Tim]
> This raises a question:  what should crc32 and adler32 return?
> ...
> binascii.crc32() always-- even on 64-bit boxes --returns a value in
> range(-2**31, 2**31).
> ...
> I don't know what the other guys return (zlib.crc32(),
> zlib.adler32(), ...?).
>
> It would sure be nice if they returned values in range(0,
> 2**32) instead.  A difficulty with changing this stuff is that
> checksums seem frequently to be read and written via the struct
> module, with format code "l", and e.g.
>
> >>> struct.pack("!l", 1L << 31)
> Traceback (most recent call last):
>   File "<stdin>", line 1, in ?
> OverflowError: long int too large to convert to int

[Guido]
> Such programs will have to be changed to use format code "L" instead.

I'm not following this.  At least binascii.crc32() always produces a 32-bit
signed int now, so there's no *need* to use "L" now.  Are you saying that
binascii.crc32() should be changed to return a non-negative value always?
Also the other xyz.abc32() functions?

> Or perhaps "l" should be allowed to accept longs in
> range(-2**31, 2**32) ?

Well, unpacking a packed value wouldn't always return the value you started
with then (pack 2**31 via "l", then unpack it via "l" and you get
back -2**31), so it's not very attractive.  If you dump a checksum via pack,
then unpack it later, you really want to get back the same value, not just
"the same bits after some fiddling".