[Python-Dev] test_gzip/test_tarfile failure om AMD64 (original) (raw)
Bob Ippolito bob at redivi.com
Mon May 29 01:48:27 CEST 2006
- Previous message: [Python-Dev] test_gzip/test_tarfile failure om AMD64
- Next message: [Python-Dev] test_gzip/test_tarfile failure om AMD64
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On May 28, 2006, at 4:31 AM, Thomas Wouters wrote:
I'm seeing a dubious failure of testgzip and testtarfile on my AMD64 machine. It's triggered by the recent struct changes, but I'd say it's probably caused by a bug/misfeature in zlibmodule: zlib.crc32 is the result of a zlib 'crc32' functioncall, which returns an unsigned long. zlib.crc32 turns that unsigned long into a (signed) Python int, which means a number beyond 1<<31 goes_ _negative on 32-bit systems and other systems with 32-bit longs, but_ _stays positive on systems with 64-bit longs:_ _(32-bit)_ _>>> zlib.crc32("foobabazr") -271938108 (64-bit) >>> zlib.crc32("foobabazr") 4023029188 The old structmodule coped with that: >>> struct.pack("<l", -271938108)_ _'\xc4\x8d\xca\xef'_ _>>> struct.pack("<l", 4023029188)_ _'\xc4\x8d\xca\xef'_ _The new one does not:_ _>>> struct.pack("<l", -271938108)_ _'\xc4\x8d\xca\xef'_ _>>> struct.pack("<l", 4023029188)_ _Traceback (most recent call last):_ _File "", line 1, in File "Lib/struct.py", line 63, in pack return o.pack(*args) struct.error: 'l' format requires -2147483647 <= number <= 2147483647 The structmodule should be fixed (and a test added ;) but I'm also wondering if zlib shouldn't be fixed. Now, I'm AMD64-centric, so my suggested fix would be to change the PyIntFromLong() call to PyLongFromUnsignedLong(), making zlib always return positive numbers -- it might break some code on 32-bit platforms, but that code is already broken on 64-bit platforms. But I guess I'm okay with the long being changed into an actual 32-bit signed number on 64-bit platforms, too.
The struct module isn't what's broken here. All of the struct types
have always had well defined bit sizes and alignment if you
explicitly specify an endian, >I and >L are 32-bits everywhere, and
Q is supported on platforms that don't have long long. The only
thing that's changed is that it actually checks for errors
consistently now.
-bob
- Previous message: [Python-Dev] test_gzip/test_tarfile failure om AMD64
- Next message: [Python-Dev] test_gzip/test_tarfile failure om AMD64
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]