On Mon, 5 Feb 2024 23:53:06 GMT, Archie Cobbs <aco...@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 with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains six additional > commits since the last revision: > > - Merge branch 'master' into JDK-7036144 > - Merge branch 'master' into JDK-7036144 > - Address third round of review comments. > - Address second round of review comments. > - Address review comments. > - Fix bug in GZIPInputStream when underlying available() returns short. Hello Archie, > Edited to add: I said "already a problem in the current code" but should > clarify: what I mean is, suppose some clever InputStream were never letting > available() return more than the number of compressed bytes remaining. That > strategy would not be reliable, because not all reads from the underlying > stream are gated with a check of what's available() (for example, see > InflaterInputStream.fill()). So I don't think we need to worry about breaking > such a case because it's already broken for other reasons. I think what you note is reasonable and accurate. I'll run some experiments against existing corpus of artifacts to see if this proposed change could cause more issues than the current state of GZIPInputStream. ------------- PR Comment: https://git.openjdk.org/jdk/pull/17113#issuecomment-1968364298
