Closed zmodem closed 7 months ago
That is not a permitted use. The stream cannot be used after Z_STREAM_END
, and the documentation in zlib says so:
After deflate has returned Z_STREAM_END, the only possible operations on the stream are deflateReset or deflateEnd.
deflateBound()
returns 22 in your case after initialization, after any deflate()
call that does not return Z_STREAM_END
, and after a deflateReset()
that follows the Z_STREAM_END
. So it is working as intended.
Also it is a non-sensical use. There is no value in the information if the stream cannot even be used. There is no use for the information if the compression is done, and you already know the actual length, as opposed to a bound. If you intend to reuse the stream, then you would get the bound after the reset.
Having said all that, I have updated the code to be more conservative.
Consider the following test program which calls
deflateBound()
afterdeflate()
has run (and finished):The returned bound is lower than the actual output size:
Calling it like that may seem unusual, but the manual doesn't forbid it:
and the code looks like it's supposed to handle it, for example with this state check:
https://github.com/madler/zlib/blob/5c42a230b7b468dff011f444161c0145b5efae59/deflate.c#L849-L851
In the test program above, it seems the code fails to figure out what wrapper the stream is using, and we end up in this default case:
https://github.com/madler/zlib/blob/5c42a230b7b468dff011f444161c0145b5efae59/deflate.c#L884-L885
The "compiler happiness" comment indicates that perhaps that code is not intended to run?
That code (and also the code above if
deflateStateCheck()
fails) seems to assume a zlib wrapper, which is smaller than a gzip one.So there seems to be two issues:
(Tested at the current
develop
branch, 5c42a230b7b468dff011f444161c0145b5efae59)