3

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, zfree and opaque must be initialized before by the caller.

yet in the next paragraph:

... So next_in, and avail_in, next_out, and avail_out are 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, zfree and opaque must be initialized before by the caller.

Why the asymmetry?

1 Answer 1

1

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.

2
  • Thank you, Mark, for chiming in! :-) I do hope a future version will not brake this because in cases where a compressor is prepared to receive messages long before they start to arrive, an explicit step will be required to defer deflateInit().
    – neoxic
    Commented Jan 30, 2022 at 1:52
  • ...will not break this...
    – neoxic
    Commented Jan 31, 2022 at 1:51

Not the answer you're looking for? Browse other questions tagged or ask your own question.