On Sun, May 12, 2013 at 4:49 AM, Paul Eggert <egg...@cs.ucla.edu> wrote: > Ah, OK, if I'm understanding you correctly, the problem > is merely the wording of the diagnostics. Sometimes gzip is > saying "trailing garbage ignored", sometimes "unexpected EOF". > This has to do with, internally, how it looks for the gzip > header; the exact spelling of the diagnostic isn't that > significant. Since one can concatenate gzip files, the > distinction between trailing garbage and unexpected EOF > isn't always clear, anyway.
Initial goal was to find the end of a gzip file in a concatenated binary file. in the test case empty file I would expect the result and exit status to be "unexpected end of file" when extracting less than 20 bytes from the test-file. I would expect the result and exit status to be "OK" using 20 bytes and I would expect the result and exit status to be "decompression OK, trailing zero bytes ignored" using 21 bytes or more. In the cases I've seen so far all test results on 21-byte files (i.e. empty + 1 byte) is "to short" which is incorrect. -- GRTNX, RobJE
