[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".
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4