Serhiy Storchaka <storch...@gmail.com> added the comment: > 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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue14315> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
