GNU bug report logs - #75924
maint: fix s390 buffer flushes

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Eduard Stefes <Eduard.Stefes <at> ibm.com>
Cc: "75924 <at> debbugs.gnu.org" <75924 <at> debbugs.gnu.org>, "iii <at> linux.ibm.com" <iii <at> linux.ibm.com>, "andreas.hasenack <at> canonical.com" <andreas.hasenack <at> canonical.com>
Subject: bug#75924: maint: fix s390 buffer flushes
Date: Thu, 6 Feb 2025 10:20:18 -0800

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?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.