Stefan Alfredsson wrote:
>> return struct.pack('>i',self.value)
>
> This assumes that self.value should be signed. A problem might arise if it
> should really be unsigned.
>
> self.value is assigned from _crc32, which calls zlib.crc32.
> According to pydoc, "The returned checksum is an integer."
> According to intuition, a checksum should not be negative (?).
>
> I'll have to look closer at this.Interesting indeed. According to http://bugs.python.org/issue1202, "The functions zlib.crc32() and zlib.adler32() return a signed value in the range(-2147483648, 2147483648) on 32-bit platforms, but an unsigned value in the range(0, 4294967296) on 64-bit platforms. This means that half the possible answers are numerically different on these two kinds of platforms." This was later fixed, such that 3.0 always returns unsigned. 2.6 always returns signed, 2**31...2**31-1 come back as negative integers. and they note in http://svn.python.org/view?rev=61459&view=rev "zlib.crc32 and zlib.adler32 now return an unsigned value as any sane person would expect. Fixes issues1202." So it seems that the long-term solution is to have an unsigned value, but in current versions it might be either signed or unsigned, depending on 32 or 64 bit archs. Argh! One solution suggested was to use x = zlib.adler32(mystr) & 0xffffffffL which would force it to be unsigned, and thus work with capital I. Matthew/Upstream, do you have an opionion in this matter? Regards, Stefan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
