CODEWITHSUNDEEP
compressionzlibdeflate
neoxic
neoxic

Reputation: 565

Zlib deflate/inflate proper initialization

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?

Upvotes: 3

Views: 614

Answers (1)

Mark Adler
Mark Adler

Reputation: 112374

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.

Upvotes: 1

Related Questions