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