Issue 4903: binascii.crc32() - document signed vs unsigned results (original) (raw)

Issue4903

Created on 2009-01-10 02:57 by beazley, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Messages (10)
msg79524 - (view)	Author: David M. Beazley (beazley)	Date: 2009-01-10 02:57
The result of binascii.crc32() is different on the same input in Python 2.6/3.0. For example: Python 2.6: >>> binascii.crc32('Hello') -137262718 Python 3.0: >>> binascii.crc32(b'Hello') 4157704578
msg79526 - (view)	Author: Gregory P. Smith (gregory.p.smith) *	Date: 2009-01-10 03:06
When treated as an unsigned 32bit value those are identical. Guido prefers to keep Python 2.x always having signed values for the scattered crc functions. We changed it for 3.0 because it makes more sense given that python these days no real fixed-bits numeric type. See also http://bugs.python.org/issue1202 I posted a workaround in there. Always & the crc32() or adler32() return value with 0xFFFFFFFF.
msg79529 - (view)	Author: David M. Beazley (beazley)	Date: 2009-01-10 03:16
Can someone PLEASE make sure this gets documented someplace.
msg79534 - (view)	Author: Martin v. Löwis (loewis) *	Date: 2009-01-10 09:24
What is "this" that you want to get documented? Can you propose a specific wording?
msg79542 - (view)	Author: David M. Beazley (beazley)	Date: 2009-01-10 12:12
Placing a note in the standard library documentation would be a start. Just say in Python 3.0 it always returns the result as an unsigned integer whereas in Python 2.6 a 32-bit signed integer is returned. Although the numerical value may differ between versions, the underlying bits are the same. Use crc32() & 0xffffffff to get a consistent value (already noted). Note: Not everyone uses checksums in only a packed-binary format. Having the integer value just change across Python versions like that is a real subtle compatibility problem to point out.
msg79591 - (view)	Author: Gregory P. Smith (gregory.p.smith) *	Date: 2009-01-11 07:22
Agreed, we failed to mention the behavior change in the docs. I'll take care of that. (if its mentioned at all, its mentioned in a note buried in the Misc/NEWS file somewhere) 2to3 could presumably be made to notice crc32 and adler32 calls and warn about this problem. I wouldn't have 2to3 add code to re-sign the return value by default as not everything needs that but it is worthy of a warning.
msg79606 - (view)	Author: Gregory P. Smith (gregory.p.smith) *	Date: 2009-01-11 18:00
binascii and zlib documentation updated in trunk r68535. I'll close the issue after I've merged it into release26-maint, release30-maint and py3k. Any objections to the wording? http://svn.python.org/view/python/trunk/Doc/library/binascii.rst? rev=68535&view=diff&r1=68535&r2=68534&p1=python/trunk/Doc/library/binasc ii.rst&p2=/python/trunk/Doc/library/binascii.rst
msg79715 - (view)	Author: Gabriel Genellina (ggenellina)	Date: 2009-01-13 02:21
Just a small note on the wording: "will have" and "will always be" look too strong to me. I'd just use is, are. Present tense seems to be --in general-- the preferred style in the documentation.
msg80893 - (view)	Author: Gregory P. Smith (gregory.p.smith) *	Date: 2009-02-01 00:16
wording updated in r69159, thanks.
msg80894 - (view)	Author: Gregory P. Smith (gregory.p.smith) *	Date: 2009-02-01 00:31
and r69161, r69160, r69162, r69163, r69164.