Re: ZipInputStream brokenness

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Adam" == Adam Megacz <gcj@lists.megacz.com> writes:

Adam> Okay, I've complained about this before. Libgcj's java.util.zip
Adam> is broken.

I looked at this a bit today.  ZipInputStream has some problems.  The
fill() method is suspect.  read() checks against `avail', but we can
have avail==0 when reading an unknown-size compressed file.  skip()
also does this.  closeEntry() doesn't skip the file contents in this
case.  There may be CRC calculation problems (there is a FIXME but I
don't know if it is out of date).

So, it's a mess :-(

Adam> Can we replace it with Jazzlib (pure Java, no native code) at
Adam> least until somebody steps up and fixes the native code version?
Adam> IMHO correctness is more important than performance.

I also tend to prefer correctness.  However, in this case, the problem
isn't really related to Jazzlib.  We could possibly start using the
Classpath ZipInputStream (though I imagine it would require more work
than a simple `cp') here.

Last time this came up, Per made the good point that zlib is more
mature and better tested than Jazzlib.  So for correctness it is
perhaps better to continue to rely on it.  Merging the other parts of
java.util.zip with Classpath would be beneficial, though.

Tom