Paul, All looks good. Though for the NEWS I would just say “a well-formed streamed zip file.” Any streaming zipper could trigger the issue. For example, Info-ZIPs zip streams a zip file that does not work with 1.14, but does work with the new patches. I would consider it rather more likely that such a zip file would have been made by zip, as opposed to pigz. pigz's normal use is with .gz files. Also, it’s not all that unusual to run across streamed zip files. The ability to stream is why data descriptors were added to the format.
By the way, in experimenting with Info-ZIP’s zip, I noticed that it likes to put a Zip64 extra field in the local header even when it's not needed. I will provide a patch to gzip to process the Zip64 extra field, to replace the current “unsupported” error message. Mark > On Jun 16, 2025, at 1:00 PM, Paul Eggert <egg...@cs.ucla.edu> wrote: > > Thanks for the patches, Mark! I installed them, added a regression test, and > adjusted the new code to match GNU style (which is what we do for gzip > nowadays). While I was at it I added static checks against bizarre but > standard-conforming values of EOF, something that has been bugging me for a > while. > > For the record I'm attaching the patches involved, and I'm closing the bug > report. > > oset: if you would like your name and email address in the THANKS file, > please let me know your name or nom de plume.
