On 2025-02-05 07:46, Eduard Stefes wrote:
We think that the only
possibility for a problem here, is if faulty hardware updates param->cf
incorrect.
I'd rather not worry about hardware going bad, unless the hardware
failure is a known real-world problem. So how about if we make the
following further patch?
diff --git a/dfltcc.c b/dfltcc.c
index 9f86581..a360ce2 100644
--- a/dfltcc.c
+++ b/dfltcc.c
@@ -372,7 +372,7 @@ dfltcc_deflate (int pack_level)
/* Read the input data. */
if (inptr == insize)
{
- if (fill_inbuf (1) == EOF && !param->cf)
+ if (fill_inbuf (1) == EOF)
break;
inptr = 0;
}
I read rfc1952 and there is no explicit statement saying that
incomplete gz files *are corrupt or invalid*.
My reading is that the RFC does not specify any behavior for incomplete
gz files. However, gzip goes beyond what the RFC requires, and is
supposed to complain "unexpected end of file" for incomplete files,
versus "invalid compressed data--format violated" for files that are not
prefixes of valid compressed files. We should maintain that behavior as
it is valuable information to give to the user.
I installed the patch to dfltcc.c that you suggested in
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=75924#5>, superseding the
incorrect patch I installed a couple of days ago. However, I'm worried
about the patch to test/hufts that you also suggested, as it would mean
gzip's diagnostics would differ on s390. As I understand it, test/hufts
checks for invalid data not unexpected EOF, so for these tests gzip
should say "invalid compressed data" rather than "unexpected end of
file", which means that there's still a bug in the s390 port that
relates to which diagnostic to give in this case.
Am I understanding this correctly?
