New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
zlib.crc32() and adler32() return value #45543
Comments
The functions zlib.crc32() and zlib.adler32() return a signed value Ideally, this should be fixed by having them always return unsigned |
Since it's basically a magic cookie, not a meaningful numeric value, I'd return x - ((x & 0x80000000) <<1) anyone? |
Both CRC-32 and ADLER32 are standards (described in ISO 3309 and RFC ISO 3309 isn't available online as far as I can see, but CRC-32 |
The C reference code in rfc1950 for Adler-32 and in rfc1952 for CRC-32 |
How about, in Python 2.6 we make the 64-bit version return a signed |
Obscure but reasonable. (I suspect you meant to say that py3k should |
Yes. :) |
working on this now. foo = 'abcdefghijklmnop' 2.x 32-bit long: zlib.crc32(foo) returns -1808088941 This is because PyInt_FromLong() happily fits the value into a signed I'm doing as guido suggests and leaving this slightly odd behavior for |
question: should I also make 64-bit 2.x return a signed value as well to Consistency in case someone ever pickles the value and sends it to |
Sure. (Though sending pickles to 3.0 would still cause problems. |
I store CRC in reed-solomon schema of mine. I compare with equality, so, I will need to touch my code in python 3.0, but that will be inevitable |
fixed. 3.0 always returns unsigned. trunk r61449 |
In case it isn't obvious the work around for pre 3.0 to get the right |
The workaround I prefer to use is: x = zlib.adler32(mystr) & 0xffffffffL |
Let me reopen this, I think we have an issue with this fix. The conclusion of this discussion so far is that in 3.0 the crc32 will The documentation for 2.6, the commit message for the fix and what it's This is *not* actually happening: >>> s = "*"*100000
>>> print zlib.crc32(s) # 2.6, 32 bits
-872059092
>>> print zlib.crc32(s) # 2.6, 64 bits
3422908204 The problem in the code is, IMHO, that the "32b rounding" is being Thank you! |
An int is 32-bits on all popular platforms. Anyways i'll double check |
I believe I have hit this bug. With Python 2.6.1 in a Gentoo Linux This code: from zipfile import ZipFile
inzip = ZipFile('Document.odt')
outzip = ZipFile('out.zip', 'w')
for f in inzip.infolist():
if f.filename != 'content.xml':
print f.filename, '(CRC: %s)' % f.CRC
outzip.writestr(f, inzip.read(f.filename))
outzip.close() Produces this output: ... The CRC is not a 32bits signed, and then the module struct complains, zipfile.py:1098 Apparently 'struct.pack' expects 'zinfo.CRC' to be a 32 signed it, I can attach the 'Document.odt' file if you want. |
seems there are bugs with it not staying signed as it should on some |
err not 3.0.x, 3.0 is always unsigned like anyone sane would want. :) |
J. David Ibáñez - do you still happen to have that Document.odt laying |
There it is. |
Regarding the issue J. David Ibáñez has, I have a few comments to add:
I'm not sure whether or not a separate bug report should be opened for |
fix for J. David's issue submitted to trunk r73565 and py3k r73566 just in release30-maint r73567 |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: