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

Previous Next

Full log

View this message in rfc822 format

From: Eduard Stefes <Eduard.Stefes <at> ibm.com>
To: "eggert <at> cs.ucla.edu" <eggert <at> cs.ucla.edu>
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: Wed, 29 Jan 2025 19:50:03 +0000

Hi,

On Wed, 2025-01-29 at 10:58 -0800, Paul Eggert wrote:
> Thanks for the bug report. I installed the attached, a bit simpler
> than 
> the patch you suggested; can you please give it a try?
changing the call fill_inbuff(1) to fill_inbuff(0) will not work.
dfltcc works on the outbuf, and fill_inbuff will eventually call
flush_window in case it hits EOF && 0. But it will NOT call
flush_outbuf() which we need in this case.



> 
> Also, is there a related bug near dfltcc.c line 375? That is, when 
> (inptr == insize && fill_inbuf (1) == EOF && param->cf), won't insize
> then be zero, so that gzip will go into an infinite loop attempting
> to 
> read past EOF?
I will think about this and try to come up with a test for it. To me it
looks like inbuf is preallocated (gzip.c:135) so it might be ok to read
past EOF and just compress zeros. The logic around it should prevent
access past inbuf[MAX]. But better be save then sorry.  

In that matter, should I extract the failing gzip tests from rsyslog
and add them to the gzip test suit?

-- 
Eduard Stefes <Eduard.Stefes <at> ibm.com>

Previous Next

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