Message74380
| Author |
facundobatista |
| Recipients |
arigo, facundobatista, gregory.p.smith, gvanrossum, jcea, mbecker, tlesher |
| Date |
2008年10月06日.16:10:42 |
| SpamBayes Score |
2.8664293e-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! |
|