Lines Matching full:deflate
11 We often get questions about how the <tt>deflate()</tt> and <tt>inflate()</tt> functions should be used.
16 from an input file to an output file using <tt>deflate()</tt> and <tt>inflate()</tt> respectively. The
22 /* zpipe.c: example of proper use of zlib's inflate() and deflate()
44 <tt>deflate()</tt>, and <tt>deflateEnd()</tt>, and the basic decompression
91 return codes. <tt>flush</tt> will keep track of the current flushing state for <tt>deflate()</tt>,
93 <tt>have</tt> is the amount of data returned from <tt>deflate()</tt>. The <tt>strm</tt> structure
95 <tt>deflate()</tt> state. <tt>in</tt> and <tt>out</tt> are the input and output buffers for
96 <tt>deflate()</tt>.
105 <tt>deflateInit()</tt>. This must be done before the first use of <tt>deflate()</tt>.
139 /* allocate deflate state */
149 This loop contains the only call of <tt>deflate()</tt>. So we must make sure that all of the
159 <em>zlib</em> constant <tt>Z_FINISH</tt>, which is later passed to <tt>deflate()</tt> to
163 the fact that we got to the end-of-file, and not know to tell <tt>deflate()</tt> to finish
165 constant <tt>Z_NO_FLUSH</tt> will be passed to <tt>deflate</tt> to indicate that we are still
183 The inner <tt>do</tt>-loop passes our chunk of input data to <tt>deflate()</tt>, and then
184 keeps calling <tt>deflate()</tt> until it is done producing output. Once there is no more
185 new output, <tt>deflate()</tt> is guaranteed to have consumed all of the input, i.e.,
188 /* run deflate() on input until output buffer not full, finish
192 Output space is provided to <tt>deflate()</tt> by setting <tt>avail_out</tt> to the number
198 Now we call the compression engine itself, <tt>deflate()</tt>. It takes as many of the
205 and <tt>next_in</tt> are updated by <tt>deflate()</tt>, we don't have to mess with those
206 between <tt>deflate()</tt> calls until it's all used up.
208 The parameters to <tt>deflate()</tt> are a pointer to the <tt>strm</tt> structure containing
210 indicating whether and how to flush data to the output. Normally <tt>deflate</tt> will consume
214 <tt>deflate()</tt>
216 write out the trailer check value. <tt>deflate()</tt> will continue to compress normally as long
218 <tt>deflate()</tt> will begin to complete the compressed output stream. However depending on how
219 much output space is provided, <tt>deflate()</tt> may have to be called several times until it
224 force <tt>deflate()</tt> to produce a burst of output that encodes all of the input data provided
226 compressed data. You can also ask that <tt>deflate()</tt> do that as well as erase any history up to
231 <tt>deflate()</tt> has a return value that can indicate errors, yet we do not check it here. Why
232 not? Well, it turns out that <tt>deflate()</tt> can do no wrong here. Let's go through
233 <tt>deflate()</tt>'s return values and dispense with them one by one. The possible values are
236 <tt>deflate()</tt>. This is already guaranteed by calling <tt>deflate()</tt> with <tt>Z_FINISH</tt>
242 suffice it to say that this is simply an indication that <tt>deflate()</tt> could not consume
243 more input or produce more output. <tt>deflate()</tt> can be called again with more output space
246 ret = deflate(&strm, flush); /* no bad return value */
249 Now we compute how much output <tt>deflate()</tt> provided on the last call, which is the
252 We can then reuse the output buffer for the next call of <tt>deflate()</tt>. Again if there
261 The inner <tt>do</tt>-loop is repeated until the last <tt>deflate()</tt> call fails to fill the
262 provided output buffer. Then we know that <tt>deflate()</tt> has done as much as it can with
266 The way we tell that <tt>deflate()</tt> has no more output is by seeing that it did not fill
268 <tt>deflate()</tt> has no more output, but just so happened to exactly fill the output buffer!
269 deflate()</tt> has done all it can.
270 As far as we know, <tt>deflate()</tt>
271 has more output for us. So we call it again. But now <tt>deflate()</tt> produces no output
272 at all, and <tt>avail_out</tt> remains unchanged as <tt>CHUNK</tt>. That <tt>deflate()</tt> call
275 all. Now we finally have the desired indication that <tt>deflate()</tt> is really done,
276 and so we drop out of the inner loop to provide more input to <tt>deflate()</tt>.
278 With <tt>flush</tt> set to <tt>Z_FINISH</tt>, this final set of <tt>deflate()</tt> calls will
279 complete the output stream. Once that is done, subsequent calls of <tt>deflate()</tt> would return
283 Some applications of <em>zlib</em> have two loops that call <tt>deflate()</tt>
285 without flushing and feed all of the data to <tt>deflate()</tt>. The second loop would call
286 <tt>deflate()</tt> with no more
296 from the last <tt>deflate()</tt> call, since we ran it until the last chunk of input was
320 allocated for processing, Z_DATA_ERROR if the deflate data is
368 /* decompress until deflate stream ends or end of file */
407 needs it, unlike <tt>deflate()</tt>, whose memory is allocated at the start by <tt>deflateInit()</tt>.
410 <tt>deflateSetDictionary()</tt> to prime <tt>deflate()</tt> with a set of likely data to improve the
432 The output of <tt>inflate()</tt> is handled identically to that of <tt>deflate()</tt>.
441 by not filling the output buffer, just as for <tt>deflate()</tt>. In this case, we cannot
442 assert that <tt>strm.avail_in</tt> will be zero, since the deflate stream may end before the file
475 Note that these are only a subset of the possible return values from <tt>deflate()</tt>
493 fputs("invalid or incomplete deflate data\n", stderr);
