classification
Title: struct.pack('L', -1)
Type: Stage:
Components: Versions: Python 2.7, Python 2.6
process
Status: closed Resolution: accepted
Dependencies: Superseder:
Assigned To: Nosy List: andreas.schawo, arigo, georg.brandl, loewis, mark.dickinson
Priority: release blocker Keywords: patch

Created on 2008-10-29 15:41 by arigo, last changed 2009-03-18 13:26 by mark.dickinson. This issue is now closed.

Files
File name Uploaded Description Edit
struct-2.5-fix.diff arigo, 2008-12-11 15:20
Messages (10)
msg75319 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-10-29 15:41
struct.pack('L', -1) raises a DeprecationWarning since Python 2.5, as it
should.  However, it also returns a different (and nonsensical) result
than Python <= 2.4 used to: it returns '\x00\x00\x00\x00' instead of
'\xff\xff\xff\xff'.

This might lead the zipfile module of release25-maint (the version >=
2.5.2) to produce buggy zip files.  The -1 value can come as the
header_offset field, which will then be packed as an all-0 string
instead of an all-ff string in the zip file headers.

Given the DeprecationWarning I would classify this as low priority. 
However, given that the stdlib module zipfile relies on this feature in
release25-maint, it should probably really be fixed.
msg75320 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-10-29 15:42
Ah, I should also mention that a fix of zipfile for 2.5 to no longer use
the deprecated feature (and thus no longer cause DeprecationWarnings)
also sounds like a good idea, in addition to the fix to the struct module.
msg77497 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-10 08:34
Can you provide a fix within the next two days? Otherwise, I see little
chance that this gets fixed in 2.5.
msg77613 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-12-11 14:43
FWIW, struct.pack("I", "whatever") produces "\x00\x00\x00\x00" too.
msg77615 - (view) Author: Armin Rigo (arigo) * (Python committer) Date: 2008-12-11 15:20
Attached struct-2.5-fix.diff.  The tests still pass (both 32- and 64-bits).
msg77734 - (view) Author: Martin v. Löwis (loewis) * (Python committer) Date: 2008-12-13 14:35
Thanks for the patch. Committed (along with a test case) as r67733, in
the 2.5 branch.

Porting to the other branches still needs to happen. Armin, if you want
to make these changes, please go ahead.
msg78702 - (view) Author: Georg Brandl (georg.brandl) * (Python committer) Date: 2009-01-01 12:15
Committed to trunk in r68120.
msg83586 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-03-14 12:49
Was zipfile ever fixed to avoid this deprecated behaviour?  If not, is the 
fix fairly trivial?

It would be nice to be able to finally turn these struct deprecation 
warnings into errors in Python 3.1 and/or Python 2.7.
msg83743 - (view) Author: Andreas Schawo (andreas.schawo) Date: 2009-03-18 11:20
As I understand actually the zipfile module possibly creates damaged zip
files after version 2.4 because of '\x00\x00\x00\x00' instead of
'\xff\xff\xff\xff' as header offset. But without any error.

I think the _struct.c should be cleaned in any case. Because we only get
errors in zipfile module when damaged zip files are created. An error
would be appriciated instead of a silenty damaged zip file.

But, why don't boundary check the header offset in zipfile module in a
short private  function and returning '\xff\xff\xff\xff' in case of
overflow? Maybe all longs should be boundary checked if this seems
necassery.
msg83745 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) Date: 2009-03-18 13:26
I don't know the zipfile module very well (i.e., at all),
but as far as I can tell from looking at the source,
there's no use of struct.pack('L', -1) in 2.6 onwards:
it's only potentially a problem in 2.5 (and that isn't
going to change, now that 2.5 is in security-fix only
mode).

Can anyone who understands the zipfile module better than
me confirm this?
History
Date User Action Args
2009-03-18 13:26:02mark.dickinsonsetmessages: + msg83745
2009-03-18 11:20:18andreas.schawosetnosy: + andreas.schawo
messages: + msg83743
2009-03-14 12:49:10mark.dickinsonsetnosy: + mark.dickinson
messages: + msg83586
2009-01-01 12:15:37georg.brandlsetstatus: open -> closed
nosy: + georg.brandl
messages: + msg78702
2008-12-20 14:36:35loewissetversions: - Python 2.5, Python 2.5.3
2008-12-20 02:41:23loewissetpriority: deferred blocker -> release blocker
2008-12-13 14:37:11loewissetpriority: normal -> deferred blocker
2008-12-13 14:35:31loewissetpriority: release blocker -> normal
resolution: accepted
messages: + msg77734
2008-12-11 20:06:14loewissetpriority: release blocker
2008-12-11 15:20:57arigosetfiles: + struct-2.5-fix.diff
keywords: + patch
messages: + msg77615
2008-12-11 14:43:33arigosetmessages: + msg77613
2008-12-10 08:34:16loewissetnosy: + loewis
messages: + msg77497
2008-10-29 15:42:59arigosetmessages: + msg75320
2008-10-29 15:41:01arigocreate