RFR: 7036144: GZIPInputStream readTrailer uses faulty available() test for end-of-stream [v4]

[Archie Cobbs]

On Tue, 19 Dec 2023 08:11:42 GMT, Bernd <duke at openjdk.org> wrote:

> > If what you're saying is "Previously we were implicitly verifying that the data reported by `available()` was actually there, and now we're no longer verifying that" then that's not correct.
> 
> I mean it verified the non-zero behavior, not that the data length was correct. Not sure if that is somewhere tested now.

Ok gotcha.

The test `GZIPInputStreamRead.java` verifies that `available()` returns zero once all of the compressed data has been read out. So this verifies `available()` at the end of a stream. It doesn't appear there are any tests which verify `available()` in the middle of a stream. Adding such a test would be a great idea but is beyond the scope of this bug of course.

In any case, I don't think the code that was there before was providing much in the way of implicit testing of `available()` either:

// try concatenated case
if (this.in.available() > 0 || n > 26) {
    int m = 8;                  // this.trailer
    try {
        m += readHeader(in);    // next.header
    } catch (IOException ze) {
        return true;  // ignore any malformed, do nothing
    }
    inf.reset();
    if (n > m)
        inf.setInput(buf, len - n + m, n - m);
    return false;
}
return true;

As you can see, in the previous version, when `available() > 0`, there would be no noticeable side effect if there was actually less data than that ("do nothing").

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1863006155