On Tue, 19 Dec 2023 08:11:42 GMT, Bernd <[email protected]> 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
