xref: /netbsd-src/external/gpl3/binutils.old/dist/zlib/examples/zlib_how.html (revision 16dce51364ebe8aeafbae46bc5aa167b8115bc45)
1*16dce513Schristos<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"
2*16dce513Schristos  "http://www.w3.org/TR/REC-html40/loose.dtd">
3*16dce513Schristos<html>
4*16dce513Schristos<head>
5*16dce513Schristos<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
6*16dce513Schristos<title>zlib Usage Example</title>
7*16dce513Schristos<!--  Copyright (c) 2004, 2005 Mark Adler.  -->
8*16dce513Schristos</head>
9*16dce513Schristos<body bgcolor="#FFFFFF" text="#000000" link="#0000FF" vlink="#00A000">
10*16dce513Schristos<h2 align="center"> zlib Usage Example </h2>
11*16dce513SchristosWe often get questions about how the <tt>deflate()</tt> and <tt>inflate()</tt> functions should be used.
12*16dce513SchristosUsers wonder when they should provide more input, when they should use more output,
13*16dce513Schristoswhat to do with a <tt>Z_BUF_ERROR</tt>, how to make sure the process terminates properly, and
14*16dce513Schristosso on.  So for those who have read <tt>zlib.h</tt> (a few times), and
15*16dce513Schristoswould like further edification, below is an annotated example in C of simple routines to compress and decompress
16*16dce513Schristosfrom an input file to an output file using <tt>deflate()</tt> and <tt>inflate()</tt> respectively.  The
17*16dce513Schristosannotations are interspersed between lines of the code.  So please read between the lines.
18*16dce513SchristosWe hope this helps explain some of the intricacies of <em>zlib</em>.
19*16dce513Schristos<p>
20*16dce513SchristosWithout further adieu, here is the program <a href="zpipe.c"><tt>zpipe.c</tt></a>:
21*16dce513Schristos<pre><b>
22*16dce513Schristos/* zpipe.c: example of proper use of zlib's inflate() and deflate()
23*16dce513Schristos   Not copyrighted -- provided to the public domain
24*16dce513Schristos   Version 1.4  11 December 2005  Mark Adler */
25*16dce513Schristos
26*16dce513Schristos/* Version history:
27*16dce513Schristos   1.0  30 Oct 2004  First version
28*16dce513Schristos   1.1   8 Nov 2004  Add void casting for unused return values
29*16dce513Schristos                     Use switch statement for inflate() return values
30*16dce513Schristos   1.2   9 Nov 2004  Add assertions to document zlib guarantees
31*16dce513Schristos   1.3   6 Apr 2005  Remove incorrect assertion in inf()
32*16dce513Schristos   1.4  11 Dec 2005  Add hack to avoid MSDOS end-of-line conversions
33*16dce513Schristos                     Avoid some compiler warnings for input and output buffers
34*16dce513Schristos */
35*16dce513Schristos</b></pre><!-- -->
36*16dce513SchristosWe now include the header files for the required definitions.  From
37*16dce513Schristos<tt>stdio.h</tt> we use <tt>fopen()</tt>, <tt>fread()</tt>, <tt>fwrite()</tt>,
38*16dce513Schristos<tt>feof()</tt>, <tt>ferror()</tt>, and <tt>fclose()</tt> for file i/o, and
39*16dce513Schristos<tt>fputs()</tt> for error messages.  From <tt>string.h</tt> we use
40*16dce513Schristos<tt>strcmp()</tt> for command line argument processing.
41*16dce513SchristosFrom <tt>assert.h</tt> we use the <tt>assert()</tt> macro.
42*16dce513SchristosFrom <tt>zlib.h</tt>
43*16dce513Schristoswe use the basic compression functions <tt>deflateInit()</tt>,
44*16dce513Schristos<tt>deflate()</tt>, and <tt>deflateEnd()</tt>, and the basic decompression
45*16dce513Schristosfunctions <tt>inflateInit()</tt>, <tt>inflate()</tt>, and
46*16dce513Schristos<tt>inflateEnd()</tt>.
47*16dce513Schristos<pre><b>
48*16dce513Schristos#include &lt;stdio.h&gt;
49*16dce513Schristos#include &lt;string.h&gt;
50*16dce513Schristos#include &lt;assert.h&gt;
51*16dce513Schristos#include "zlib.h"
52*16dce513Schristos</b></pre><!-- -->
53*16dce513SchristosThis is an ugly hack required to avoid corruption of the input and output data on
54*16dce513SchristosWindows/MS-DOS systems.  Without this, those systems would assume that the input and output
55*16dce513Schristosfiles are text, and try to convert the end-of-line characters from one standard to
56*16dce513Schristosanother.  That would corrupt binary data, and in particular would render the compressed data unusable.
57*16dce513SchristosThis sets the input and output to binary which suppresses the end-of-line conversions.
58*16dce513Schristos<tt>SET_BINARY_MODE()</tt> will be used later on <tt>stdin</tt> and <tt>stdout</tt>, at the beginning of <tt>main()</tt>.
59*16dce513Schristos<pre><b>
60*16dce513Schristos#if defined(MSDOS) || defined(OS2) || defined(WIN32) || defined(__CYGWIN__)
61*16dce513Schristos#  include &lt;fcntl.h&gt;
62*16dce513Schristos#  include &lt;io.h&gt;
63*16dce513Schristos#  define SET_BINARY_MODE(file) setmode(fileno(file), O_BINARY)
64*16dce513Schristos#else
65*16dce513Schristos#  define SET_BINARY_MODE(file)
66*16dce513Schristos#endif
67*16dce513Schristos</b></pre><!-- -->
68*16dce513Schristos<tt>CHUNK</tt> is simply the buffer size for feeding data to and pulling data
69*16dce513Schristosfrom the <em>zlib</em> routines.  Larger buffer sizes would be more efficient,
70*16dce513Schristosespecially for <tt>inflate()</tt>.  If the memory is available, buffers sizes
71*16dce513Schristoson the order of 128K or 256K bytes should be used.
72*16dce513Schristos<pre><b>
73*16dce513Schristos#define CHUNK 16384
74*16dce513Schristos</b></pre><!-- -->
75*16dce513SchristosThe <tt>def()</tt> routine compresses data from an input file to an output file.  The output data
76*16dce513Schristoswill be in the <em>zlib</em> format, which is different from the <em>gzip</em> or <em>zip</em>
77*16dce513Schristosformats.  The <em>zlib</em> format has a very small header of only two bytes to identify it as
78*16dce513Schristosa <em>zlib</em> stream and to provide decoding information, and a four-byte trailer with a fast
79*16dce513Schristoscheck value to verify the integrity of the uncompressed data after decoding.
80*16dce513Schristos<pre><b>
81*16dce513Schristos/* Compress from file source to file dest until EOF on source.
82*16dce513Schristos   def() returns Z_OK on success, Z_MEM_ERROR if memory could not be
83*16dce513Schristos   allocated for processing, Z_STREAM_ERROR if an invalid compression
84*16dce513Schristos   level is supplied, Z_VERSION_ERROR if the version of zlib.h and the
85*16dce513Schristos   version of the library linked do not match, or Z_ERRNO if there is
86*16dce513Schristos   an error reading or writing the files. */
87*16dce513Schristosint def(FILE *source, FILE *dest, int level)
88*16dce513Schristos{
89*16dce513Schristos</b></pre>
90*16dce513SchristosHere are the local variables for <tt>def()</tt>.  <tt>ret</tt> will be used for <em>zlib</em>
91*16dce513Schristosreturn codes.  <tt>flush</tt> will keep track of the current flushing state for <tt>deflate()</tt>,
92*16dce513Schristoswhich is either no flushing, or flush to completion after the end of the input file is reached.
93*16dce513Schristos<tt>have</tt> is the amount of data returned from <tt>deflate()</tt>.  The <tt>strm</tt> structure
94*16dce513Schristosis used to pass information to and from the <em>zlib</em> routines, and to maintain the
95*16dce513Schristos<tt>deflate()</tt> state.  <tt>in</tt> and <tt>out</tt> are the input and output buffers for
96*16dce513Schristos<tt>deflate()</tt>.
97*16dce513Schristos<pre><b>
98*16dce513Schristos    int ret, flush;
99*16dce513Schristos    unsigned have;
100*16dce513Schristos    z_stream strm;
101*16dce513Schristos    unsigned char in[CHUNK];
102*16dce513Schristos    unsigned char out[CHUNK];
103*16dce513Schristos</b></pre><!-- -->
104*16dce513SchristosThe first thing we do is to initialize the <em>zlib</em> state for compression using
105*16dce513Schristos<tt>deflateInit()</tt>.  This must be done before the first use of <tt>deflate()</tt>.
106*16dce513SchristosThe <tt>zalloc</tt>, <tt>zfree</tt>, and <tt>opaque</tt> fields in the <tt>strm</tt>
107*16dce513Schristosstructure must be initialized before calling <tt>deflateInit()</tt>.  Here they are
108*16dce513Schristosset to the <em>zlib</em> constant <tt>Z_NULL</tt> to request that <em>zlib</em> use
109*16dce513Schristosthe default memory allocation routines.  An application may also choose to provide
110*16dce513Schristoscustom memory allocation routines here.  <tt>deflateInit()</tt> will allocate on the
111*16dce513Schristosorder of 256K bytes for the internal state.
112*16dce513Schristos(See <a href="zlib_tech.html"><em>zlib Technical Details</em></a>.)
113*16dce513Schristos<p>
114*16dce513Schristos<tt>deflateInit()</tt> is called with a pointer to the structure to be initialized and
115*16dce513Schristosthe compression level, which is an integer in the range of -1 to 9.  Lower compression
116*16dce513Schristoslevels result in faster execution, but less compression.  Higher levels result in
117*16dce513Schristosgreater compression, but slower execution.  The <em>zlib</em> constant Z_DEFAULT_COMPRESSION,
118*16dce513Schristosequal to -1,
119*16dce513Schristosprovides a good compromise between compression and speed and is equivalent to level 6.
120*16dce513SchristosLevel 0 actually does no compression at all, and in fact expands the data slightly to produce
121*16dce513Schristosthe <em>zlib</em> format (it is not a byte-for-byte copy of the input).
122*16dce513SchristosMore advanced applications of <em>zlib</em>
123*16dce513Schristosmay use <tt>deflateInit2()</tt> here instead.  Such an application may want to reduce how
124*16dce513Schristosmuch memory will be used, at some price in compression.  Or it may need to request a
125*16dce513Schristos<em>gzip</em> header and trailer instead of a <em>zlib</em> header and trailer, or raw
126*16dce513Schristosencoding with no header or trailer at all.
127*16dce513Schristos<p>
128*16dce513SchristosWe must check the return value of <tt>deflateInit()</tt> against the <em>zlib</em> constant
129*16dce513Schristos<tt>Z_OK</tt> to make sure that it was able to
130*16dce513Schristosallocate memory for the internal state, and that the provided arguments were valid.
131*16dce513Schristos<tt>deflateInit()</tt> will also check that the version of <em>zlib</em> that the <tt>zlib.h</tt>
132*16dce513Schristosfile came from matches the version of <em>zlib</em> actually linked with the program.  This
133*16dce513Schristosis especially important for environments in which <em>zlib</em> is a shared library.
134*16dce513Schristos<p>
135*16dce513SchristosNote that an application can initialize multiple, independent <em>zlib</em> streams, which can
136*16dce513Schristosoperate in parallel.  The state information maintained in the structure allows the <em>zlib</em>
137*16dce513Schristosroutines to be reentrant.
138*16dce513Schristos<pre><b>
139*16dce513Schristos    /* allocate deflate state */
140*16dce513Schristos    strm.zalloc = Z_NULL;
141*16dce513Schristos    strm.zfree = Z_NULL;
142*16dce513Schristos    strm.opaque = Z_NULL;
143*16dce513Schristos    ret = deflateInit(&amp;strm, level);
144*16dce513Schristos    if (ret != Z_OK)
145*16dce513Schristos        return ret;
146*16dce513Schristos</b></pre><!-- -->
147*16dce513SchristosWith the pleasantries out of the way, now we can get down to business.  The outer <tt>do</tt>-loop
148*16dce513Schristosreads all of the input file and exits at the bottom of the loop once end-of-file is reached.
149*16dce513SchristosThis loop contains the only call of <tt>deflate()</tt>.  So we must make sure that all of the
150*16dce513Schristosinput data has been processed and that all of the output data has been generated and consumed
151*16dce513Schristosbefore we fall out of the loop at the bottom.
152*16dce513Schristos<pre><b>
153*16dce513Schristos    /* compress until end of file */
154*16dce513Schristos    do {
155*16dce513Schristos</b></pre>
156*16dce513SchristosWe start off by reading data from the input file.  The number of bytes read is put directly
157*16dce513Schristosinto <tt>avail_in</tt>, and a pointer to those bytes is put into <tt>next_in</tt>.  We also
158*16dce513Schristoscheck to see if end-of-file on the input has been reached.  If we are at the end of file, then <tt>flush</tt> is set to the
159*16dce513Schristos<em>zlib</em> constant <tt>Z_FINISH</tt>, which is later passed to <tt>deflate()</tt> to
160*16dce513Schristosindicate that this is the last chunk of input data to compress.  We need to use <tt>feof()</tt>
161*16dce513Schristosto check for end-of-file as opposed to seeing if fewer than <tt>CHUNK</tt> bytes have been read.  The
162*16dce513Schristosreason is that if the input file length is an exact multiple of <tt>CHUNK</tt>, we will miss
163*16dce513Schristosthe fact that we got to the end-of-file, and not know to tell <tt>deflate()</tt> to finish
164*16dce513Schristosup the compressed stream.  If we are not yet at the end of the input, then the <em>zlib</em>
165*16dce513Schristosconstant <tt>Z_NO_FLUSH</tt> will be passed to <tt>deflate</tt> to indicate that we are still
166*16dce513Schristosin the middle of the uncompressed data.
167*16dce513Schristos<p>
168*16dce513SchristosIf there is an error in reading from the input file, the process is aborted with
169*16dce513Schristos<tt>deflateEnd()</tt> being called to free the allocated <em>zlib</em> state before returning
170*16dce513Schristosthe error.  We wouldn't want a memory leak, now would we?  <tt>deflateEnd()</tt> can be called
171*16dce513Schristosat any time after the state has been initialized.  Once that's done, <tt>deflateInit()</tt> (or
172*16dce513Schristos<tt>deflateInit2()</tt>) would have to be called to start a new compression process.  There is
173*16dce513Schristosno point here in checking the <tt>deflateEnd()</tt> return code.  The deallocation can't fail.
174*16dce513Schristos<pre><b>
175*16dce513Schristos        strm.avail_in = fread(in, 1, CHUNK, source);
176*16dce513Schristos        if (ferror(source)) {
177*16dce513Schristos            (void)deflateEnd(&amp;strm);
178*16dce513Schristos            return Z_ERRNO;
179*16dce513Schristos        }
180*16dce513Schristos        flush = feof(source) ? Z_FINISH : Z_NO_FLUSH;
181*16dce513Schristos        strm.next_in = in;
182*16dce513Schristos</b></pre><!-- -->
183*16dce513SchristosThe inner <tt>do</tt>-loop passes our chunk of input data to <tt>deflate()</tt>, and then
184*16dce513Schristoskeeps calling <tt>deflate()</tt> until it is done producing output.  Once there is no more
185*16dce513Schristosnew output, <tt>deflate()</tt> is guaranteed to have consumed all of the input, i.e.,
186*16dce513Schristos<tt>avail_in</tt> will be zero.
187*16dce513Schristos<pre><b>
188*16dce513Schristos        /* run deflate() on input until output buffer not full, finish
189*16dce513Schristos           compression if all of source has been read in */
190*16dce513Schristos        do {
191*16dce513Schristos</b></pre>
192*16dce513SchristosOutput space is provided to <tt>deflate()</tt> by setting <tt>avail_out</tt> to the number
193*16dce513Schristosof available output bytes and <tt>next_out</tt> to a pointer to that space.
194*16dce513Schristos<pre><b>
195*16dce513Schristos            strm.avail_out = CHUNK;
196*16dce513Schristos            strm.next_out = out;
197*16dce513Schristos</b></pre>
198*16dce513SchristosNow we call the compression engine itself, <tt>deflate()</tt>.  It takes as many of the
199*16dce513Schristos<tt>avail_in</tt> bytes at <tt>next_in</tt> as it can process, and writes as many as
200*16dce513Schristos<tt>avail_out</tt> bytes to <tt>next_out</tt>.  Those counters and pointers are then
201*16dce513Schristosupdated past the input data consumed and the output data written.  It is the amount of
202*16dce513Schristosoutput space available that may limit how much input is consumed.
203*16dce513SchristosHence the inner loop to make sure that
204*16dce513Schristosall of the input is consumed by providing more output space each time.  Since <tt>avail_in</tt>
205*16dce513Schristosand <tt>next_in</tt> are updated by <tt>deflate()</tt>, we don't have to mess with those
206*16dce513Schristosbetween <tt>deflate()</tt> calls until it's all used up.
207*16dce513Schristos<p>
208*16dce513SchristosThe parameters to <tt>deflate()</tt> are a pointer to the <tt>strm</tt> structure containing
209*16dce513Schristosthe input and output information and the internal compression engine state, and a parameter
210*16dce513Schristosindicating whether and how to flush data to the output.  Normally <tt>deflate</tt> will consume
211*16dce513Schristosseveral K bytes of input data before producing any output (except for the header), in order
212*16dce513Schristosto accumulate statistics on the data for optimum compression.  It will then put out a burst of
213*16dce513Schristoscompressed data, and proceed to consume more input before the next burst.  Eventually,
214*16dce513Schristos<tt>deflate()</tt>
215*16dce513Schristosmust be told to terminate the stream, complete the compression with provided input data, and
216*16dce513Schristoswrite out the trailer check value.  <tt>deflate()</tt> will continue to compress normally as long
217*16dce513Schristosas the flush parameter is <tt>Z_NO_FLUSH</tt>.  Once the <tt>Z_FINISH</tt> parameter is provided,
218*16dce513Schristos<tt>deflate()</tt> will begin to complete the compressed output stream.  However depending on how
219*16dce513Schristosmuch output space is provided, <tt>deflate()</tt> may have to be called several times until it
220*16dce513Schristoshas provided the complete compressed stream, even after it has consumed all of the input.  The flush
221*16dce513Schristosparameter must continue to be <tt>Z_FINISH</tt> for those subsequent calls.
222*16dce513Schristos<p>
223*16dce513SchristosThere are other values of the flush parameter that are used in more advanced applications.  You can
224*16dce513Schristosforce <tt>deflate()</tt> to produce a burst of output that encodes all of the input data provided
225*16dce513Schristosso far, even if it wouldn't have otherwise, for example to control data latency on a link with
226*16dce513Schristoscompressed data.  You can also ask that <tt>deflate()</tt> do that as well as erase any history up to
227*16dce513Schristosthat point so that what follows can be decompressed independently, for example for random access
228*16dce513Schristosapplications.  Both requests will degrade compression by an amount depending on how often such
229*16dce513Schristosrequests are made.
230*16dce513Schristos<p>
231*16dce513Schristos<tt>deflate()</tt> has a return value that can indicate errors, yet we do not check it here.  Why
232*16dce513Schristosnot?  Well, it turns out that <tt>deflate()</tt> can do no wrong here.  Let's go through
233*16dce513Schristos<tt>deflate()</tt>'s return values and dispense with them one by one.  The possible values are
234*16dce513Schristos<tt>Z_OK</tt>, <tt>Z_STREAM_END</tt>, <tt>Z_STREAM_ERROR</tt>, or <tt>Z_BUF_ERROR</tt>.  <tt>Z_OK</tt>
235*16dce513Schristosis, well, ok.  <tt>Z_STREAM_END</tt> is also ok and will be returned for the last call of
236*16dce513Schristos<tt>deflate()</tt>.  This is already guaranteed by calling <tt>deflate()</tt> with <tt>Z_FINISH</tt>
237*16dce513Schristosuntil it has no more output.  <tt>Z_STREAM_ERROR</tt> is only possible if the stream is not
238*16dce513Schristosinitialized properly, but we did initialize it properly.  There is no harm in checking for
239*16dce513Schristos<tt>Z_STREAM_ERROR</tt> here, for example to check for the possibility that some
240*16dce513Schristosother part of the application inadvertently clobbered the memory containing the <em>zlib</em> state.
241*16dce513Schristos<tt>Z_BUF_ERROR</tt> will be explained further below, but
242*16dce513Schristossuffice it to say that this is simply an indication that <tt>deflate()</tt> could not consume
243*16dce513Schristosmore input or produce more output.  <tt>deflate()</tt> can be called again with more output space
244*16dce513Schristosor more available input, which it will be in this code.
245*16dce513Schristos<pre><b>
246*16dce513Schristos            ret = deflate(&amp;strm, flush);    /* no bad return value */
247*16dce513Schristos            assert(ret != Z_STREAM_ERROR);  /* state not clobbered */
248*16dce513Schristos</b></pre>
249*16dce513SchristosNow we compute how much output <tt>deflate()</tt> provided on the last call, which is the
250*16dce513Schristosdifference between how much space was provided before the call, and how much output space
251*16dce513Schristosis still available after the call.  Then that data, if any, is written to the output file.
252*16dce513SchristosWe can then reuse the output buffer for the next call of <tt>deflate()</tt>.  Again if there
253*16dce513Schristosis a file i/o error, we call <tt>deflateEnd()</tt> before returning to avoid a memory leak.
254*16dce513Schristos<pre><b>
255*16dce513Schristos            have = CHUNK - strm.avail_out;
256*16dce513Schristos            if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
257*16dce513Schristos                (void)deflateEnd(&amp;strm);
258*16dce513Schristos                return Z_ERRNO;
259*16dce513Schristos            }
260*16dce513Schristos</b></pre>
261*16dce513SchristosThe inner <tt>do</tt>-loop is repeated until the last <tt>deflate()</tt> call fails to fill the
262*16dce513Schristosprovided output buffer.  Then we know that <tt>deflate()</tt> has done as much as it can with
263*16dce513Schristosthe provided input, and that all of that input has been consumed.  We can then fall out of this
264*16dce513Schristosloop and reuse the input buffer.
265*16dce513Schristos<p>
266*16dce513SchristosThe way we tell that <tt>deflate()</tt> has no more output is by seeing that it did not fill
267*16dce513Schristosthe output buffer, leaving <tt>avail_out</tt> greater than zero.  However suppose that
268*16dce513Schristos<tt>deflate()</tt> has no more output, but just so happened to exactly fill the output buffer!
269*16dce513Schristos<tt>avail_out</tt> is zero, and we can't tell that <tt>deflate()</tt> has done all it can.
270*16dce513SchristosAs far as we know, <tt>deflate()</tt>
271*16dce513Schristoshas more output for us.  So we call it again.  But now <tt>deflate()</tt> produces no output
272*16dce513Schristosat all, and <tt>avail_out</tt> remains unchanged as <tt>CHUNK</tt>.  That <tt>deflate()</tt> call
273*16dce513Schristoswasn't able to do anything, either consume input or produce output, and so it returns
274*16dce513Schristos<tt>Z_BUF_ERROR</tt>.  (See, I told you I'd cover this later.)  However this is not a problem at
275*16dce513Schristosall.  Now we finally have the desired indication that <tt>deflate()</tt> is really done,
276*16dce513Schristosand so we drop out of the inner loop to provide more input to <tt>deflate()</tt>.
277*16dce513Schristos<p>
278*16dce513SchristosWith <tt>flush</tt> set to <tt>Z_FINISH</tt>, this final set of <tt>deflate()</tt> calls will
279*16dce513Schristoscomplete the output stream.  Once that is done, subsequent calls of <tt>deflate()</tt> would return
280*16dce513Schristos<tt>Z_STREAM_ERROR</tt> if the flush parameter is not <tt>Z_FINISH</tt>, and do no more processing
281*16dce513Schristosuntil the state is reinitialized.
282*16dce513Schristos<p>
283*16dce513SchristosSome applications of <em>zlib</em> have two loops that call <tt>deflate()</tt>
284*16dce513Schristosinstead of the single inner loop we have here.  The first loop would call
285*16dce513Schristoswithout flushing and feed all of the data to <tt>deflate()</tt>.  The second loop would call
286*16dce513Schristos<tt>deflate()</tt> with no more
287*16dce513Schristosdata and the <tt>Z_FINISH</tt> parameter to complete the process.  As you can see from this
288*16dce513Schristosexample, that can be avoided by simply keeping track of the current flush state.
289*16dce513Schristos<pre><b>
290*16dce513Schristos        } while (strm.avail_out == 0);
291*16dce513Schristos        assert(strm.avail_in == 0);     /* all input will be used */
292*16dce513Schristos</b></pre><!-- -->
293*16dce513SchristosNow we check to see if we have already processed all of the input file.  That information was
294*16dce513Schristossaved in the <tt>flush</tt> variable, so we see if that was set to <tt>Z_FINISH</tt>.  If so,
295*16dce513Schristosthen we're done and we fall out of the outer loop.  We're guaranteed to get <tt>Z_STREAM_END</tt>
296*16dce513Schristosfrom the last <tt>deflate()</tt> call, since we ran it until the last chunk of input was
297*16dce513Schristosconsumed and all of the output was generated.
298*16dce513Schristos<pre><b>
299*16dce513Schristos        /* done when last data in file processed */
300*16dce513Schristos    } while (flush != Z_FINISH);
301*16dce513Schristos    assert(ret == Z_STREAM_END);        /* stream will be complete */
302*16dce513Schristos</b></pre><!-- -->
303*16dce513SchristosThe process is complete, but we still need to deallocate the state to avoid a memory leak
304*16dce513Schristos(or rather more like a memory hemorrhage if you didn't do this).  Then
305*16dce513Schristosfinally we can return with a happy return value.
306*16dce513Schristos<pre><b>
307*16dce513Schristos    /* clean up and return */
308*16dce513Schristos    (void)deflateEnd(&amp;strm);
309*16dce513Schristos    return Z_OK;
310*16dce513Schristos}
311*16dce513Schristos</b></pre><!-- -->
312*16dce513SchristosNow we do the same thing for decompression in the <tt>inf()</tt> routine. <tt>inf()</tt>
313*16dce513Schristosdecompresses what is hopefully a valid <em>zlib</em> stream from the input file and writes the
314*16dce513Schristosuncompressed data to the output file.  Much of the discussion above for <tt>def()</tt>
315*16dce513Schristosapplies to <tt>inf()</tt> as well, so the discussion here will focus on the differences between
316*16dce513Schristosthe two.
317*16dce513Schristos<pre><b>
318*16dce513Schristos/* Decompress from file source to file dest until stream ends or EOF.
319*16dce513Schristos   inf() returns Z_OK on success, Z_MEM_ERROR if memory could not be
320*16dce513Schristos   allocated for processing, Z_DATA_ERROR if the deflate data is
321*16dce513Schristos   invalid or incomplete, Z_VERSION_ERROR if the version of zlib.h and
322*16dce513Schristos   the version of the library linked do not match, or Z_ERRNO if there
323*16dce513Schristos   is an error reading or writing the files. */
324*16dce513Schristosint inf(FILE *source, FILE *dest)
325*16dce513Schristos{
326*16dce513Schristos</b></pre>
327*16dce513SchristosThe local variables have the same functionality as they do for <tt>def()</tt>.  The
328*16dce513Schristosonly difference is that there is no <tt>flush</tt> variable, since <tt>inflate()</tt>
329*16dce513Schristoscan tell from the <em>zlib</em> stream itself when the stream is complete.
330*16dce513Schristos<pre><b>
331*16dce513Schristos    int ret;
332*16dce513Schristos    unsigned have;
333*16dce513Schristos    z_stream strm;
334*16dce513Schristos    unsigned char in[CHUNK];
335*16dce513Schristos    unsigned char out[CHUNK];
336*16dce513Schristos</b></pre><!-- -->
337*16dce513SchristosThe initialization of the state is the same, except that there is no compression level,
338*16dce513Schristosof course, and two more elements of the structure are initialized.  <tt>avail_in</tt>
339*16dce513Schristosand <tt>next_in</tt> must be initialized before calling <tt>inflateInit()</tt>.  This
340*16dce513Schristosis because the application has the option to provide the start of the zlib stream in
341*16dce513Schristosorder for <tt>inflateInit()</tt> to have access to information about the compression
342*16dce513Schristosmethod to aid in memory allocation.  In the current implementation of <em>zlib</em>
343*16dce513Schristos(up through versions 1.2.x), the method-dependent memory allocations are deferred to the first call of
344*16dce513Schristos<tt>inflate()</tt> anyway.  However those fields must be initialized since later versions
345*16dce513Schristosof <em>zlib</em> that provide more compression methods may take advantage of this interface.
346*16dce513SchristosIn any case, no decompression is performed by <tt>inflateInit()</tt>, so the
347*16dce513Schristos<tt>avail_out</tt> and <tt>next_out</tt> fields do not need to be initialized before calling.
348*16dce513Schristos<p>
349*16dce513SchristosHere <tt>avail_in</tt> is set to zero and <tt>next_in</tt> is set to <tt>Z_NULL</tt> to
350*16dce513Schristosindicate that no input data is being provided.
351*16dce513Schristos<pre><b>
352*16dce513Schristos    /* allocate inflate state */
353*16dce513Schristos    strm.zalloc = Z_NULL;
354*16dce513Schristos    strm.zfree = Z_NULL;
355*16dce513Schristos    strm.opaque = Z_NULL;
356*16dce513Schristos    strm.avail_in = 0;
357*16dce513Schristos    strm.next_in = Z_NULL;
358*16dce513Schristos    ret = inflateInit(&amp;strm);
359*16dce513Schristos    if (ret != Z_OK)
360*16dce513Schristos        return ret;
361*16dce513Schristos</b></pre><!-- -->
362*16dce513SchristosThe outer <tt>do</tt>-loop decompresses input until <tt>inflate()</tt> indicates
363*16dce513Schristosthat it has reached the end of the compressed data and has produced all of the uncompressed
364*16dce513Schristosoutput.  This is in contrast to <tt>def()</tt> which processes all of the input file.
365*16dce513SchristosIf end-of-file is reached before the compressed data self-terminates, then the compressed
366*16dce513Schristosdata is incomplete and an error is returned.
367*16dce513Schristos<pre><b>
368*16dce513Schristos    /* decompress until deflate stream ends or end of file */
369*16dce513Schristos    do {
370*16dce513Schristos</b></pre>
371*16dce513SchristosWe read input data and set the <tt>strm</tt> structure accordingly.  If we've reached the
372*16dce513Schristosend of the input file, then we leave the outer loop and report an error, since the
373*16dce513Schristoscompressed data is incomplete.  Note that we may read more data than is eventually consumed
374*16dce513Schristosby <tt>inflate()</tt>, if the input file continues past the <em>zlib</em> stream.
375*16dce513SchristosFor applications where <em>zlib</em> streams are embedded in other data, this routine would
376*16dce513Schristosneed to be modified to return the unused data, or at least indicate how much of the input
377*16dce513Schristosdata was not used, so the application would know where to pick up after the <em>zlib</em> stream.
378*16dce513Schristos<pre><b>
379*16dce513Schristos        strm.avail_in = fread(in, 1, CHUNK, source);
380*16dce513Schristos        if (ferror(source)) {
381*16dce513Schristos            (void)inflateEnd(&amp;strm);
382*16dce513Schristos            return Z_ERRNO;
383*16dce513Schristos        }
384*16dce513Schristos        if (strm.avail_in == 0)
385*16dce513Schristos            break;
386*16dce513Schristos        strm.next_in = in;
387*16dce513Schristos</b></pre><!-- -->
388*16dce513SchristosThe inner <tt>do</tt>-loop has the same function it did in <tt>def()</tt>, which is to
389*16dce513Schristoskeep calling <tt>inflate()</tt> until has generated all of the output it can with the
390*16dce513Schristosprovided input.
391*16dce513Schristos<pre><b>
392*16dce513Schristos        /* run inflate() on input until output buffer not full */
393*16dce513Schristos        do {
394*16dce513Schristos</b></pre>
395*16dce513SchristosJust like in <tt>def()</tt>, the same output space is provided for each call of <tt>inflate()</tt>.
396*16dce513Schristos<pre><b>
397*16dce513Schristos            strm.avail_out = CHUNK;
398*16dce513Schristos            strm.next_out = out;
399*16dce513Schristos</b></pre>
400*16dce513SchristosNow we run the decompression engine itself.  There is no need to adjust the flush parameter, since
401*16dce513Schristosthe <em>zlib</em> format is self-terminating. The main difference here is that there are
402*16dce513Schristosreturn values that we need to pay attention to.  <tt>Z_DATA_ERROR</tt>
403*16dce513Schristosindicates that <tt>inflate()</tt> detected an error in the <em>zlib</em> compressed data format,
404*16dce513Schristoswhich means that either the data is not a <em>zlib</em> stream to begin with, or that the data was
405*16dce513Schristoscorrupted somewhere along the way since it was compressed.  The other error to be processed is
406*16dce513Schristos<tt>Z_MEM_ERROR</tt>, which can occur since memory allocation is deferred until <tt>inflate()</tt>
407*16dce513Schristosneeds it, unlike <tt>deflate()</tt>, whose memory is allocated at the start by <tt>deflateInit()</tt>.
408*16dce513Schristos<p>
409*16dce513SchristosAdvanced applications may use
410*16dce513Schristos<tt>deflateSetDictionary()</tt> to prime <tt>deflate()</tt> with a set of likely data to improve the
411*16dce513Schristosfirst 32K or so of compression.  This is noted in the <em>zlib</em> header, so <tt>inflate()</tt>
412*16dce513Schristosrequests that that dictionary be provided before it can start to decompress.  Without the dictionary,
413*16dce513Schristoscorrect decompression is not possible.  For this routine, we have no idea what the dictionary is,
414*16dce513Schristosso the <tt>Z_NEED_DICT</tt> indication is converted to a <tt>Z_DATA_ERROR</tt>.
415*16dce513Schristos<p>
416*16dce513Schristos<tt>inflate()</tt> can also return <tt>Z_STREAM_ERROR</tt>, which should not be possible here,
417*16dce513Schristosbut could be checked for as noted above for <tt>def()</tt>.  <tt>Z_BUF_ERROR</tt> does not need to be
418*16dce513Schristoschecked for here, for the same reasons noted for <tt>def()</tt>.  <tt>Z_STREAM_END</tt> will be
419*16dce513Schristoschecked for later.
420*16dce513Schristos<pre><b>
421*16dce513Schristos            ret = inflate(&amp;strm, Z_NO_FLUSH);
422*16dce513Schristos            assert(ret != Z_STREAM_ERROR);  /* state not clobbered */
423*16dce513Schristos            switch (ret) {
424*16dce513Schristos            case Z_NEED_DICT:
425*16dce513Schristos                ret = Z_DATA_ERROR;     /* and fall through */
426*16dce513Schristos            case Z_DATA_ERROR:
427*16dce513Schristos            case Z_MEM_ERROR:
428*16dce513Schristos                (void)inflateEnd(&amp;strm);
429*16dce513Schristos                return ret;
430*16dce513Schristos            }
431*16dce513Schristos</b></pre>
432*16dce513SchristosThe output of <tt>inflate()</tt> is handled identically to that of <tt>deflate()</tt>.
433*16dce513Schristos<pre><b>
434*16dce513Schristos            have = CHUNK - strm.avail_out;
435*16dce513Schristos            if (fwrite(out, 1, have, dest) != have || ferror(dest)) {
436*16dce513Schristos                (void)inflateEnd(&amp;strm);
437*16dce513Schristos                return Z_ERRNO;
438*16dce513Schristos            }
439*16dce513Schristos</b></pre>
440*16dce513SchristosThe inner <tt>do</tt>-loop ends when <tt>inflate()</tt> has no more output as indicated
441*16dce513Schristosby not filling the output buffer, just as for <tt>deflate()</tt>.  In this case, we cannot
442*16dce513Schristosassert that <tt>strm.avail_in</tt> will be zero, since the deflate stream may end before the file
443*16dce513Schristosdoes.
444*16dce513Schristos<pre><b>
445*16dce513Schristos        } while (strm.avail_out == 0);
446*16dce513Schristos</b></pre><!-- -->
447*16dce513SchristosThe outer <tt>do</tt>-loop ends when <tt>inflate()</tt> reports that it has reached the
448*16dce513Schristosend of the input <em>zlib</em> stream, has completed the decompression and integrity
449*16dce513Schristoscheck, and has provided all of the output.  This is indicated by the <tt>inflate()</tt>
450*16dce513Schristosreturn value <tt>Z_STREAM_END</tt>.  The inner loop is guaranteed to leave <tt>ret</tt>
451*16dce513Schristosequal to <tt>Z_STREAM_END</tt> if the last chunk of the input file read contained the end
452*16dce513Schristosof the <em>zlib</em> stream.  So if the return value is not <tt>Z_STREAM_END</tt>, the
453*16dce513Schristosloop continues to read more input.
454*16dce513Schristos<pre><b>
455*16dce513Schristos        /* done when inflate() says it's done */
456*16dce513Schristos    } while (ret != Z_STREAM_END);
457*16dce513Schristos</b></pre><!-- -->
458*16dce513SchristosAt this point, decompression successfully completed, or we broke out of the loop due to no
459*16dce513Schristosmore data being available from the input file.  If the last <tt>inflate()</tt> return value
460*16dce513Schristosis not <tt>Z_STREAM_END</tt>, then the <em>zlib</em> stream was incomplete and a data error
461*16dce513Schristosis returned.  Otherwise, we return with a happy return value.  Of course, <tt>inflateEnd()</tt>
462*16dce513Schristosis called first to avoid a memory leak.
463*16dce513Schristos<pre><b>
464*16dce513Schristos    /* clean up and return */
465*16dce513Schristos    (void)inflateEnd(&amp;strm);
466*16dce513Schristos    return ret == Z_STREAM_END ? Z_OK : Z_DATA_ERROR;
467*16dce513Schristos}
468*16dce513Schristos</b></pre><!-- -->
469*16dce513SchristosThat ends the routines that directly use <em>zlib</em>.  The following routines make this
470*16dce513Schristosa command-line program by running data through the above routines from <tt>stdin</tt> to
471*16dce513Schristos<tt>stdout</tt>, and handling any errors reported by <tt>def()</tt> or <tt>inf()</tt>.
472*16dce513Schristos<p>
473*16dce513Schristos<tt>zerr()</tt> is used to interpret the possible error codes from <tt>def()</tt>
474*16dce513Schristosand <tt>inf()</tt>, as detailed in their comments above, and print out an error message.
475*16dce513SchristosNote that these are only a subset of the possible return values from <tt>deflate()</tt>
476*16dce513Schristosand <tt>inflate()</tt>.
477*16dce513Schristos<pre><b>
478*16dce513Schristos/* report a zlib or i/o error */
479*16dce513Schristosvoid zerr(int ret)
480*16dce513Schristos{
481*16dce513Schristos    fputs("zpipe: ", stderr);
482*16dce513Schristos    switch (ret) {
483*16dce513Schristos    case Z_ERRNO:
484*16dce513Schristos        if (ferror(stdin))
485*16dce513Schristos            fputs("error reading stdin\n", stderr);
486*16dce513Schristos        if (ferror(stdout))
487*16dce513Schristos            fputs("error writing stdout\n", stderr);
488*16dce513Schristos        break;
489*16dce513Schristos    case Z_STREAM_ERROR:
490*16dce513Schristos        fputs("invalid compression level\n", stderr);
491*16dce513Schristos        break;
492*16dce513Schristos    case Z_DATA_ERROR:
493*16dce513Schristos        fputs("invalid or incomplete deflate data\n", stderr);
494*16dce513Schristos        break;
495*16dce513Schristos    case Z_MEM_ERROR:
496*16dce513Schristos        fputs("out of memory\n", stderr);
497*16dce513Schristos        break;
498*16dce513Schristos    case Z_VERSION_ERROR:
499*16dce513Schristos        fputs("zlib version mismatch!\n", stderr);
500*16dce513Schristos    }
501*16dce513Schristos}
502*16dce513Schristos</b></pre><!-- -->
503*16dce513SchristosHere is the <tt>main()</tt> routine used to test <tt>def()</tt> and <tt>inf()</tt>.  The
504*16dce513Schristos<tt>zpipe</tt> command is simply a compression pipe from <tt>stdin</tt> to <tt>stdout</tt>, if
505*16dce513Schristosno arguments are given, or it is a decompression pipe if <tt>zpipe -d</tt> is used.  If any other
506*16dce513Schristosarguments are provided, no compression or decompression is performed.  Instead a usage
507*16dce513Schristosmessage is displayed.  Examples are <tt>zpipe < foo.txt > foo.txt.z</tt> to compress, and
508*16dce513Schristos<tt>zpipe -d < foo.txt.z > foo.txt</tt> to decompress.
509*16dce513Schristos<pre><b>
510*16dce513Schristos/* compress or decompress from stdin to stdout */
511*16dce513Schristosint main(int argc, char **argv)
512*16dce513Schristos{
513*16dce513Schristos    int ret;
514*16dce513Schristos
515*16dce513Schristos    /* avoid end-of-line conversions */
516*16dce513Schristos    SET_BINARY_MODE(stdin);
517*16dce513Schristos    SET_BINARY_MODE(stdout);
518*16dce513Schristos
519*16dce513Schristos    /* do compression if no arguments */
520*16dce513Schristos    if (argc == 1) {
521*16dce513Schristos        ret = def(stdin, stdout, Z_DEFAULT_COMPRESSION);
522*16dce513Schristos        if (ret != Z_OK)
523*16dce513Schristos            zerr(ret);
524*16dce513Schristos        return ret;
525*16dce513Schristos    }
526*16dce513Schristos
527*16dce513Schristos    /* do decompression if -d specified */
528*16dce513Schristos    else if (argc == 2 &amp;&amp; strcmp(argv[1], "-d") == 0) {
529*16dce513Schristos        ret = inf(stdin, stdout);
530*16dce513Schristos        if (ret != Z_OK)
531*16dce513Schristos            zerr(ret);
532*16dce513Schristos        return ret;
533*16dce513Schristos    }
534*16dce513Schristos
535*16dce513Schristos    /* otherwise, report usage */
536*16dce513Schristos    else {
537*16dce513Schristos        fputs("zpipe usage: zpipe [-d] &lt; source &gt; dest\n", stderr);
538*16dce513Schristos        return 1;
539*16dce513Schristos    }
540*16dce513Schristos}
541*16dce513Schristos</b></pre>
542*16dce513Schristos<hr>
543*16dce513Schristos<i>Copyright (c) 2004, 2005 by Mark Adler<br>Last modified 11 December 2005</i>
544*16dce513Schristos</body>
545*16dce513Schristos</html>
546