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

[Guido van Rossum]

> [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.

[Tim]
> 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?

Um, I thought *you* were proposing that!  What else did you mean by
"It would sure be nice if they returned values in range(0, 2**32)
instead" ?

> > 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".

Yeah, you can't win. :-(

--Guido van Rossum (home page: http://www.python.org/~guido/)