On Tue, 19 Dec 2023 08:11:42 GMT, Bernd <d...@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

Reply via email to