This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author serhiy.storchaka
Recipients alanmcintyre, eric.araujo, loewis, mark.dickinson, meador.inge, pleed, serhiy.storchaka, terry.reedy, ubershmekel
Date 2012-05-14.17:31:14
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1337016833.3422.28.camel@raxxla>
In-reply-to <1336958441.23.0.971269097314.issue14315@psf.upfronthosting.co.za>
Content
> This is definitely *not* a padding issue.

This is definitely a padding issue. All uncompressed files are located
so that the data starts with a 4-byte boundary (1190+30+15+1=1236, 27486
+30+17+3=27536, etc). This is, probably, allows the use of mmap for the
resources.

> As Martin pointed out, the standard says that things must be in 
> multiples of 4-bytes.

More precisely, the extra field must have at least 4-bytes length to fit
a header. The standard is insufficiently defined in terms of what would
happen if the rest of the field is less than 4 bytes (this is hidden
behind by ellipsis).

>   So the record is non-portable.

De jure the record is non-portable. De facto the record is portable
(many other tools supports it). But even if it does not portable, we are
dealing with the expansion of the zip format, which is very easy support
for reading.
History
Date User Action Args
2012-05-14 17:31:14serhiy.storchakasetrecipients: + serhiy.storchaka, loewis, terry.reedy, mark.dickinson, alanmcintyre, eric.araujo, ubershmekel, meador.inge, pleed
2012-05-14 17:31:14serhiy.storchakalinkissue14315 messages
2012-05-14 17:31:14serhiy.storchakacreate