Message160645
| 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. |
|