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.

Author facundobatista
Recipients arigo, facundobatista, gregory.p.smith, gvanrossum, jcea, mbecker, tlesher
Date 2008-10-06.16:10:42
SpamBayes Score 2.86643e-12
Marked as misclassified No
Message-id <1223309444.43.0.0899092256305.issue1202@psf.upfronthosting.co.za>
In-reply-to
Content
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
behave like the standard, which is a good thing (tm), but in 2.6 it will
not: it should return a signed integer. I agree with this outcome!

The documentation for 2.6, the commit message for the fix and what it's
said here states that: "2.6 always returns signed, 2**31...2**31-1 come
back as negative integers."

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
forced by assigning the result to an int (Modules/zlibmodule.c, line
929), but this "rounding" does not actually work for 64b (because the
int has 64 bit, and even as it's signed, the number stays big and positive).

Thank you!
History
Date User Action Args
2008-10-06 16:10:45facundobatistasetrecipients: + facundobatista, gvanrossum, arigo, gregory.p.smith, jcea, tlesher, mbecker
2008-10-06 16:10:44facundobatistasetmessageid: <1223309444.43.0.0899092256305.issue1202@psf.upfronthosting.co.za>
2008-10-06 16:10:43facundobatistalinkissue1202 messages
2008-10-06 16:10:42facundobatistacreate