On Mon, 19 Sep 2005 12:07:00 +0200
Alan Barrett <apb@cequrux.com> wrote:

> On Mon, 19 Sep 2005, Mike M. Volokhov wrote:
> > Folks, could you please take a look at the quick patch below? Now, if
> > input data is great than 4G, gzip will produce warning only (with exit
> > code = 0) and will set uncompressed file size to zero rather junk.
> 
> OK, so you propose to store 0 in the 32-bit size field of the trailer
> if the file is too large.  The gzip folk, on the other hand, seem to
> have decided to let gzip continue to store (size & 0xffffffff) in the
> 32-bit size field, and to make gunzip verify that (size & 0xffffffff) is
> correct.  (See the patch in http://www.gzip.org/4g-patch.tar.)  I expect
> that the difference will lead to interoperability problems.

Well, better is the enemy of good enough!

After examining NetBSD gzip code more carefuly, I've found it already
implements that 4g-patch (lines 963-972 of gzip.c). Thus, my patch also
will break "gzip -d" for files > 4G.  :-O

So, let me correct my fault:

Index: gzip.c
===================================================================
RCS file: /usr/home/mishka/NetBSD-CVS/src/usr.bin/gzip/gzip.c,v
retrieving revision 1.76
diff -u -r1.76 gzip.c
--- gzip.c	15 Sep 2005 18:51:33 -0000	1.76
+++ gzip.c	19 Sep 2005 12:22:18 -0000
@@ -637,8 +637,10 @@
 		 (int)(in_tot >> 24) & 0xff);
 	if (i != 8)
 		maybe_err("snprintf");
-	if (in_tot > 0xffffffff)
-		maybe_warn("input file size >= 4GB cannot be saved");
+	if (in_tot > 0xffffffff && qflag == 0) {
+		errno = EFBIG;
+		warn("warning: gzip -l output will not be trustworthy");
+	}
 	if (write(out, outbufp, i) != i) {
 		maybe_warn("write");
 		in_tot = -1;

--
Mishka.