When is GZIPDecompressorInputStream exhausted

General JUCE discussion
1

I’m not shure if it is a bug, or if my expectations are wrong. It seems to me that the implementation of GZIPDecompressorInputStream::isExhausted does not always returns the correct result.

A convenient way to work with streams is following scheme:

while (!stream.isExhausted())
{
  // read data from stream
}

Up to now this worked well with FileInputStreams and MemoryInputStreams. But when I do it this way with a GZIPDecompressorInputStream it does not work.

I found out that the flag GZIPDecompressorInputStream::isEof is not set when the last byte was read from the stream. In the next loop iteration the stream does not seem to be exhausted, and more data is read. When reading the first byte beyond the end of the stream, GZIPDecompressorInputStream realizes that there is no more data, and sets its isEof Flag.
Is this correct behaviour?

2

If the stream has some internal buffer (like Gzip for its decoding buffer), then it seems natural to me that the last byte of the (compressed) data is not always the last byte of output data.
But as far as I understand your sample code it should still work, you’ll do an extra iteration here and that’s all.

3

Yeah, not sure how possible it’d be to make the eof marker look ahead to see if it really is the end-of-file… If you can suggest a tweak that would make it work, I’d consider it, but haven’t time to dissect the class right now.