On Mon, 14 Aug 2023 18:41:26 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> > I am not understanding your point. There is a specific order for the Zip64 > > fields based on which fields have the Magic value. the spec does also not > > suggest that an empty Zip64 extra field can be written to the CEN when > > there is a Zip64 with data written to the LOC. > > Yes, there is a specific order of fields that should be stored in the > extended block if some of the data in the "body" is negative. But as you > pointed out in this case the empty block or block bigger than necessary to > store the size/csize/locoff is not prohibited by the spec. For example, take > a look at the code in the > [ZipEntry](https://github.com/openjdk/jdk/blob/c132176b932dd136d5c4314e08ac97d0fee7ba4d/src/java.base/share/classes/java/util/zip/ZipEntry.java#L553) > where we accept any size of that block and just checked that it has required > data in it. > > If you disagree then point to the part of the spec which blocks such sizes. This is how it is implemented by the "unzip" https://github.com/madler/zlib/blob/04f42ceca40f73e2978b50e93806c2a18c1281fc/contrib/minizip/unzip.c#L1035C68-L1035C76 , the dataSize is accepted as is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/15273#issuecomment-1677908114
