While using zlib in a "pedantic" way, I have stumbled across a couple inconsistencies I'd like to clear for myself.
For inflateInit(), the manual states:
... The fields
next_in,avail_in,zalloc,zfreeandopaquemust be initialized before by the caller.
yet in the next paragraph:
... So
next_in, andavail_in,next_out, andavail_outare unused and unchanged.
In other words, the manual requires next_in and avail_in to be initialized prior to calling inflateInit(), but at the same time, it states that they won't be used anyway. Why is that? In my case, I tried to leave them both uninitialized and initialized to zero with no problems until the moment real preparations are made before a call to deflate(). But strictly speaking, it is in violation of the manual unless "must be initialized" means I can initialize them to zeros. But why bother then?
Note that there is no such requirement for deflateInit():
... The fields
zalloc,zfreeandopaquemust be initialized before by the caller.
Why the asymmetry?
There was a thought that inflateInit() could make use of information in the compressed data header for initialization. So the interface requirement was that next_in and avail_in be initialized. As the description notes, using the phrases "current version" and "current implementation", such initialization is deferred to the calls of the inflate(). A future version of zlib might do something different. (Though I doubt it will.)
There is no plausible benefit to providing input data to deflateInit(), hence the asymmetry.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With