This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

classification
Title: zlib.crc32() not cross-platform
Type: Stage:
Components: Library (Lib) Versions: Python 2.5
process
Status: closed Resolution: not a bug
Dependencies: Superseder:
Assigned To: Nosy List: bencollver, ggenellina
Priority: normal Keywords:

Created on 2007-03-10 23:07 by bencollver, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (3)
msg31476 - (view) Author: Ben Collver (bencollver) Date: 2007-03-10 23:07
The zlib.crc32() function sometimes produces different results for the same input on big and little-endian processors.  Same for zlib.adler32().

sparc64:
>>> import zlib
>>> print zlib.adler32("--------------------------------------------------", 1)
> 3763407051
>>> print zlib.crc32("--------------------------------------------------", 1)
3044228349

i386:
>>> import zlib
>>> print zlib.adler32("--------------------------------------------------", 1)
> -531560245
>>> print zlib.crc32("--------------------------------------------------", 1)
-1250738947
msg31477 - (view) Author: Ben Collver (bencollver) Date: 2007-03-10 23:13
The extra > characters before the first results come from me pasting the results to my irc client, then copying from there and pasting here.  Sorry for any confusion.
msg31478 - (view) Author: Gabriel Genellina (ggenellina) Date: 2007-03-13 22:52
py> -531560245 & 0xffffffff
3763407051L

It's the same number (actually, the same bit pattern). The i386 version is signed, the other unsigned. The i386 platform uses a 32 bit "int"; the sparc64 uses 64 bits (I presume). 3763407051 doesnt fit in 31bits, so it's seen as a negative number.

History
Date User Action Args
2022-04-11 14:56:23adminsetgithub: 44695
2007-03-10 23:07:43bencollvercreate