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

[Bernd]

On Fri, 15 Dec 2023 21:13:07 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> `GZIPInputStream`, when looking for a concatenated stream, relies on what the underlying `InputStream` says is how many bytes are `available()`. But this is inappropriate because `InputStream.available()` is just an estimate and is allowed (for example) to always return zero.
>> 
>> The fix is to ignore what's `available()` and just proceed and see what happens. If fewer bytes are available than required, the attempt to extend to another stream is canceled just as it was before, e.g., when the next stream header couldn't be read.
>
> Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address third round of review comments.

Misuse of available() is a petpeave of mine, so I am happy to see that change and test. I wonder: if the stream does no longer depend on this available() condition to be true, does that mean it’s no longer (indirectly) verified? That behavior might not be guaranteed, but it’s still often relied upon. (I guess injecting a return 0 into the current implementation and running the tests would tell us if another test catches it?)

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

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