[From nobody Thu Sep 12 14:37:19 2019
Message-ID: <3F84558A.4020907@nc.rr.com>
Date: Wed, 08 Oct 2003 14:20:58 -0400
From: Jeff Johnson <n3npq@nc.rr.com>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: zlib@gzip.org
Subject: Two buglets in glibc-1.2.0.7
Content-Type: multipart/mixed; boundary="------------040606010405000308000808"

This is a multi-part message in MIME format.
--------------040606010405000308000808
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Hi --

Attached is a patch for 2 bugs in zlib-1.2.0.7, details at 
http://bugzilla.redhat.com:

    - fix: gzeof not set when reading compressed file (#106424).
    - fix: revert zlib.h include constants for now (#106291).

The gzeof() problem is the more serious. I chose an ultra-conservative 
patch to gzeof to
check s->x_err for Z_STREAM_END as well as checking a->z_eof.

The damage appears to be due to an attempt to handle a trailing crc in a 
set of concatenated
compressed files transparently. This causes divergence between z_err and 
z_eof. If left
up to me, I'd suggest ripping z_eof out entirely, mainly because 
duplicating state in
two variables is an accident waiting to happen. I believe there are 
several other
(unlikely, pathological)   problems in zlib-1.2.0.7 detecting eof, but 
that's just an
eyeball scan. And please forgive me if I have got the analysis wrong, 
zlib is quite
twisty, and it's difficult for me to compute all possible paths in my head.

If you do wish to nuke z_eof, I'll be happy to attempt a patch, I just 
need a compiler
and some coverage tests to ensure correctness ;-)

The other problems has to do with s/_ZLIB_H/ZLIB_H/ which breaks a 
fragile (imho)
test for internal vs. external zlib being used. I've reverted to the 
zlib-1.1.4 define for
the moment, will be perfectly happy to make the test in R more robust
    #if defined(_ZLIB_H) || defined(ZLIB_H)
should fix the fragile test if there are reasons to change the convention.

No matter what, I can/will revert the Red Hat packaging to follow 
zlib-1.2.1 behavior.

And could you change my e-mail address from <jbj#redhat.com> to 
<n3npq@nc.rr.com> please?
Apologies for my inability to do so myself.

73 de Jeff

--------------040606010405000308000808
Content-Type: text/plain;
 name="zlib-1.2.0.7-jbj.patch"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="zlib-1.2.0.7-jbj.patch"

--- zlib-1.2.0.7/gzio.c.jbj	2003-09-13 20:41:26.000000000 -0400
+++ zlib-1.2.0.7/gzio.c	2003-10-08 11:28:18.592138869 -0400
@@ -889,7 +889,13 @@
 {
     gz_stream *s = (gz_stream*)file;
 
-    return (s == NULL || s->mode != 'r') ? 0 : s->z_eof;
+    /* With concatenated compressed files that can have embedded
+     * crc trailers, z_eof is no longer the only/best indicator of EOF
+     * on a gz_stream. Handle end-of-stream error explicitly here.
+     */
+    return ((s == NULL || s->mode != 'r') ? 0 :
+	(s->z_eof ? 1 :
+	(s->z_err == Z_STREAM_END ? 1 : 0) ) );
 }
 
 /* ===========================================================================
--- zlib-1.2.0.7/zlib.h.jbj	2003-10-08 11:24:49.501467744 -0400
+++ zlib-1.2.0.7/zlib.h	2003-10-08 11:29:04.745434541 -0400
@@ -28,8 +28,8 @@
   (zlib format), rfc1951.txt (deflate format) and rfc1952.txt (gzip format).
 */
 
-#ifndef ZLIB_H
-#define ZLIB_H
+#ifndef _ZLIB_H
+#define _ZLIB_H
 
 #include "zconf.h"
 
@@ -1178,4 +1178,4 @@
 }
 #endif
 
-#endif /* ZLIB_H */
+#endif /* _ZLIB_H */

--------------040606010405000308000808--

]