On Wed, 28 Aug 2024 17:50:36 GMT, Lance Andersen <lan...@openjdk.org> wrote:

>> Archie Cobbs has updated the pull request incrementally with one additional 
>> commit since the last revision:
>> 
>>   Revert all functional changes, leaving only tests & Javadoc.
>
> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 43:
> 
>> 41:  * frame that marks the end of the compressed data. Therefore it's 
>> possible for the underlying
>> 42:  * input to contain additional data beyond the end of the compressed 
>> GZIP data. In particular,
>> 43:  * some GZIP compression tools function by partitioning the input, 
>> compressing each parttion
> 
> I think we need to simplify the above  keeping the focus on that 
> GZIPInputStream supports the reading of concatenated  Gzip streams.  After 
> reading  a streams trailer(though some docs refer to it as a footer, but I 
> think we go with trailer),  if an additional gzip header is found, the stream 
> will be decompressed... etc.. 
> 
> If there is additional data/byes after the trailer that does not represent 
> another gzip, header, it will indicate you have reached the end of the input 
> stream

Sounds good. How would you like to do that?

E.g. we could just remove the words "In particular, some GZIP compression tools 
function by partitioning the input, compressing each partition separately, and 
then concatenating the resulting compressed data streams. To support this kind 
of input".  We could also remove "In the latter case, the number of additional 
bytes that were read is unspecified." Or something else (what would you 
suggest?)

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18385#discussion_r1735101196

Reply via email to