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.

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.

Can you provide a fix within the next two days? Otherwise, I see little
chance that this gets fixed in 2.5.

FWIW, struct.pack("I", "whatever") produces "\x00\x00\x00\x00" too.

Attached struct-2.5-fix.diff.  The tests still pass (both 32- and 64-bits).

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.

Committed to trunk in r68120.

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.

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.

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?