Facundo Batista <[EMAIL PROTECTED]> added the comment: 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! ---------- nosy: +facundobatista resolution: fixed -> status: closed -> open _______________________________________ Python tracker <[EMAIL PROTECTED]> <http://bugs.python.org/issue1202> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
