xref: /freebsd/sys/contrib/zlib/FAQ (revision 7aa1dba6b00ccfb7d66627badc8a7aaa06b02946)
1c9083b85SXin LI
2c9083b85SXin LI                Frequently Asked Questions about zlib
3c9083b85SXin LI
4c9083b85SXin LI
5c9083b85SXin LIIf your question is not there, please check the zlib home page
6*7aa1dba6SXin LIhttps://zlib.net/ which may have more recent information.
7*7aa1dba6SXin LIThe latest zlib FAQ is at https://zlib.net/zlib_faq.html
8c9083b85SXin LI
9c9083b85SXin LI
10c9083b85SXin LI 1. Is zlib Y2K-compliant?
11c9083b85SXin LI
12c9083b85SXin LI    Yes. zlib doesn't handle dates.
13c9083b85SXin LI
14c9083b85SXin LI 2. Where can I get a Windows DLL version?
15c9083b85SXin LI
16c9083b85SXin LI    The zlib sources can be compiled without change to produce a DLL.  See the
176255c67cSXin LI    file win32/DLL_FAQ.txt in the zlib distribution.
18c9083b85SXin LI
19c9083b85SXin LI 3. Where can I get a Visual Basic interface to zlib?
20c9083b85SXin LI
21c9083b85SXin LI    See
22*7aa1dba6SXin LI        * https://zlib.net/nelson/
23c9083b85SXin LI        * win32/DLL_FAQ.txt in the zlib distribution
24c9083b85SXin LI
25c9083b85SXin LI 4. compress() returns Z_BUF_ERROR.
26c9083b85SXin LI
27c9083b85SXin LI    Make sure that before the call of compress(), the length of the compressed
28c9083b85SXin LI    buffer is equal to the available size of the compressed buffer and not
29c9083b85SXin LI    zero.  For Visual Basic, check that this parameter is passed by reference
30c9083b85SXin LI    ("as any"), not by value ("as long").
31c9083b85SXin LI
32c9083b85SXin LI 5. deflate() or inflate() returns Z_BUF_ERROR.
33c9083b85SXin LI
34c9083b85SXin LI    Before making the call, make sure that avail_in and avail_out are not zero.
35c9083b85SXin LI    When setting the parameter flush equal to Z_FINISH, also make sure that
36c9083b85SXin LI    avail_out is big enough to allow processing all pending input.  Note that a
37c9083b85SXin LI    Z_BUF_ERROR is not fatal--another call to deflate() or inflate() can be
38c9083b85SXin LI    made with more input or output space.  A Z_BUF_ERROR may in fact be
39c9083b85SXin LI    unavoidable depending on how the functions are used, since it is not
40c9083b85SXin LI    possible to tell whether or not there is more output pending when
41*7aa1dba6SXin LI    strm.avail_out returns with zero.  See https://zlib.net/zlib_how.html for a
42c9083b85SXin LI    heavily annotated example.
43c9083b85SXin LI
44c9083b85SXin LI 6. Where's the zlib documentation (man pages, etc.)?
45c9083b85SXin LI
46c9083b85SXin LI    It's in zlib.h .  Examples of zlib usage are in the files test/example.c
47c9083b85SXin LI    and test/minigzip.c, with more in examples/ .
48c9083b85SXin LI
49c9083b85SXin LI 7. Why don't you use GNU autoconf or libtool or ...?
50c9083b85SXin LI
51c9083b85SXin LI    Because we would like to keep zlib as a very small and simple package.
52c9083b85SXin LI    zlib is rather portable and doesn't need much configuration.
53c9083b85SXin LI
54c9083b85SXin LI 8. I found a bug in zlib.
55c9083b85SXin LI
56c9083b85SXin LI    Most of the time, such problems are due to an incorrect usage of zlib.
57c9083b85SXin LI    Please try to reproduce the problem with a small program and send the
58c9083b85SXin LI    corresponding source to us at zlib@gzip.org .  Do not send multi-megabyte
59c9083b85SXin LI    data files without prior agreement.
60c9083b85SXin LI
61c9083b85SXin LI 9. Why do I get "undefined reference to gzputc"?
62c9083b85SXin LI
63c9083b85SXin LI    If "make test" produces something like
64c9083b85SXin LI
65c9083b85SXin LI       example.o(.text+0x154): undefined reference to `gzputc'
66c9083b85SXin LI
67c9083b85SXin LI    check that you don't have old files libz.* in /usr/lib, /usr/local/lib or
68c9083b85SXin LI    /usr/X11R6/lib. Remove any old versions, then do "make install".
69c9083b85SXin LI
70c9083b85SXin LI10. I need a Delphi interface to zlib.
71c9083b85SXin LI
72c9083b85SXin LI    See the contrib/delphi directory in the zlib distribution.
73c9083b85SXin LI
74c9083b85SXin LI11. Can zlib handle .zip archives?
75c9083b85SXin LI
76c9083b85SXin LI    Not by itself, no.  See the directory contrib/minizip in the zlib
77c9083b85SXin LI    distribution.
78c9083b85SXin LI
79c9083b85SXin LI12. Can zlib handle .Z files?
80c9083b85SXin LI
81c9083b85SXin LI    No, sorry.  You have to spawn an uncompress or gunzip subprocess, or adapt
82c9083b85SXin LI    the code of uncompress on your own.
83c9083b85SXin LI
84c9083b85SXin LI13. How can I make a Unix shared library?
85c9083b85SXin LI
86c9083b85SXin LI    By default a shared (and a static) library is built for Unix.  So:
87c9083b85SXin LI
88c9083b85SXin LI    make distclean
89c9083b85SXin LI    ./configure
90c9083b85SXin LI    make
91c9083b85SXin LI
92c9083b85SXin LI14. How do I install a shared zlib library on Unix?
93c9083b85SXin LI
94c9083b85SXin LI    After the above, then:
95c9083b85SXin LI
96c9083b85SXin LI    make install
97c9083b85SXin LI
98c9083b85SXin LI    However, many flavors of Unix come with a shared zlib already installed.
99c9083b85SXin LI    Before going to the trouble of compiling a shared version of zlib and
100c9083b85SXin LI    trying to install it, you may want to check if it's already there!  If you
101c9083b85SXin LI    can #include <zlib.h>, it's there.  The -lz option will probably link to
102c9083b85SXin LI    it.  You can check the version at the top of zlib.h or with the
103c9083b85SXin LI    ZLIB_VERSION symbol defined in zlib.h .
104c9083b85SXin LI
105c9083b85SXin LI15. I have a question about OttoPDF.
106c9083b85SXin LI
107c9083b85SXin LI    We are not the authors of OttoPDF. The real author is on the OttoPDF web
108c9083b85SXin LI    site: Joel Hainley, jhainley@myndkryme.com.
109c9083b85SXin LI
110c9083b85SXin LI16. Can zlib decode Flate data in an Adobe PDF file?
111c9083b85SXin LI
112*7aa1dba6SXin LI    Yes. See https://www.pdflib.com/ . To modify PDF forms, see
113*7aa1dba6SXin LI    https://sourceforge.net/projects/acroformtool/ .
114c9083b85SXin LI
115c9083b85SXin LI17. Why am I getting this "register_frame_info not found" error on Solaris?
116c9083b85SXin LI
117c9083b85SXin LI    After installing zlib 1.1.4 on Solaris 2.6, running applications using zlib
118c9083b85SXin LI    generates an error such as:
119c9083b85SXin LI
120c9083b85SXin LI        ld.so.1: rpm: fatal: relocation error: file /usr/local/lib/libz.so:
121c9083b85SXin LI        symbol __register_frame_info: referenced symbol not found
122c9083b85SXin LI
123c9083b85SXin LI    The symbol __register_frame_info is not part of zlib, it is generated by
124c9083b85SXin LI    the C compiler (cc or gcc).  You must recompile applications using zlib
125c9083b85SXin LI    which have this problem.  This problem is specific to Solaris.  See
126c9083b85SXin LI    http://www.sunfreeware.com for Solaris versions of zlib and applications
127c9083b85SXin LI    using zlib.
128c9083b85SXin LI
129c9083b85SXin LI18. Why does gzip give an error on a file I make with compress/deflate?
130c9083b85SXin LI
131c9083b85SXin LI    The compress and deflate functions produce data in the zlib format, which
132c9083b85SXin LI    is different and incompatible with the gzip format.  The gz* functions in
133c9083b85SXin LI    zlib on the other hand use the gzip format.  Both the zlib and gzip formats
134c9083b85SXin LI    use the same compressed data format internally, but have different headers
135c9083b85SXin LI    and trailers around the compressed data.
136c9083b85SXin LI
137c9083b85SXin LI19. Ok, so why are there two different formats?
138c9083b85SXin LI
139c9083b85SXin LI    The gzip format was designed to retain the directory information about a
140c9083b85SXin LI    single file, such as the name and last modification date.  The zlib format
141c9083b85SXin LI    on the other hand was designed for in-memory and communication channel
142c9083b85SXin LI    applications, and has a much more compact header and trailer and uses a
143c9083b85SXin LI    faster integrity check than gzip.
144c9083b85SXin LI
145c9083b85SXin LI20. Well that's nice, but how do I make a gzip file in memory?
146c9083b85SXin LI
147c9083b85SXin LI    You can request that deflate write the gzip format instead of the zlib
148c9083b85SXin LI    format using deflateInit2().  You can also request that inflate decode the
149c9083b85SXin LI    gzip format using inflateInit2().  Read zlib.h for more details.
150c9083b85SXin LI
151c9083b85SXin LI21. Is zlib thread-safe?
152c9083b85SXin LI
153c9083b85SXin LI    Yes.  However any library routines that zlib uses and any application-
154c9083b85SXin LI    provided memory allocation routines must also be thread-safe.  zlib's gz*
155c9083b85SXin LI    functions use stdio library routines, and most of zlib's functions use the
156c9083b85SXin LI    library memory allocation routines by default.  zlib's *Init* functions
157c9083b85SXin LI    allow for the application to provide custom memory allocation routines.
158c9083b85SXin LI
159*7aa1dba6SXin LI    If the non-default BUILDFIXED or DYNAMIC_CRC_TABLE defines are used on a
160*7aa1dba6SXin LI    system without atomics (e.g. pre-C11), then inflate() and crc32() will not
161*7aa1dba6SXin LI    be thread safe.
162*7aa1dba6SXin LI
163c9083b85SXin LI    Of course, you should only operate on any given zlib or gzip stream from a
164c9083b85SXin LI    single thread at a time.
165c9083b85SXin LI
166c9083b85SXin LI22. Can I use zlib in my commercial application?
167c9083b85SXin LI
168c9083b85SXin LI    Yes.  Please read the license in zlib.h.
169c9083b85SXin LI
170c9083b85SXin LI23. Is zlib under the GNU license?
171c9083b85SXin LI
172c9083b85SXin LI    No.  Please read the license in zlib.h.
173c9083b85SXin LI
174c9083b85SXin LI24. The license says that altered source versions must be "plainly marked". So
175c9083b85SXin LI    what exactly do I need to do to meet that requirement?
176c9083b85SXin LI
177c9083b85SXin LI    You need to change the ZLIB_VERSION and ZLIB_VERNUM #defines in zlib.h.  In
178c9083b85SXin LI    particular, the final version number needs to be changed to "f", and an
179c9083b85SXin LI    identification string should be appended to ZLIB_VERSION.  Version numbers
180c9083b85SXin LI    x.x.x.f are reserved for modifications to zlib by others than the zlib
181c9083b85SXin LI    maintainers.  For example, if the version of the base zlib you are altering
182c9083b85SXin LI    is "1.2.3.4", then in zlib.h you should change ZLIB_VERNUM to 0x123f, and
183c9083b85SXin LI    ZLIB_VERSION to something like "1.2.3.f-zachary-mods-v3".  You can also
184c9083b85SXin LI    update the version strings in deflate.c and inftrees.c.
185c9083b85SXin LI
186c9083b85SXin LI    For altered source distributions, you should also note the origin and
187c9083b85SXin LI    nature of the changes in zlib.h, as well as in ChangeLog and README, along
188c9083b85SXin LI    with the dates of the alterations.  The origin should include at least your
189c9083b85SXin LI    name (or your company's name), and an email address to contact for help or
190c9083b85SXin LI    issues with the library.
191c9083b85SXin LI
192c9083b85SXin LI    Note that distributing a compiled zlib library along with zlib.h and
193c9083b85SXin LI    zconf.h is also a source distribution, and so you should change
194c9083b85SXin LI    ZLIB_VERSION and ZLIB_VERNUM and note the origin and nature of the changes
195c9083b85SXin LI    in zlib.h as you would for a full source distribution.
196c9083b85SXin LI
197c9083b85SXin LI25. Will zlib work on a big-endian or little-endian architecture, and can I
198c9083b85SXin LI    exchange compressed data between them?
199c9083b85SXin LI
200c9083b85SXin LI    Yes and yes.
201c9083b85SXin LI
202c9083b85SXin LI26. Will zlib work on a 64-bit machine?
203c9083b85SXin LI
204c9083b85SXin LI    Yes.  It has been tested on 64-bit machines, and has no dependence on any
205c9083b85SXin LI    data types being limited to 32-bits in length.  If you have any
206c9083b85SXin LI    difficulties, please provide a complete problem report to zlib@gzip.org
207c9083b85SXin LI
208c9083b85SXin LI27. Will zlib decompress data from the PKWare Data Compression Library?
209c9083b85SXin LI
210c9083b85SXin LI    No.  The PKWare DCL uses a completely different compressed data format than
211c9083b85SXin LI    does PKZIP and zlib.  However, you can look in zlib's contrib/blast
212c9083b85SXin LI    directory for a possible solution to your problem.
213c9083b85SXin LI
214c9083b85SXin LI28. Can I access data randomly in a compressed stream?
215c9083b85SXin LI
216c9083b85SXin LI    No, not without some preparation.  If when compressing you periodically use
217c9083b85SXin LI    Z_FULL_FLUSH, carefully write all the pending data at those points, and
218c9083b85SXin LI    keep an index of those locations, then you can start decompression at those
219c9083b85SXin LI    points.  You have to be careful to not use Z_FULL_FLUSH too often, since it
220c9083b85SXin LI    can significantly degrade compression.  Alternatively, you can scan a
221c9083b85SXin LI    deflate stream once to generate an index, and then use that index for
222c9083b85SXin LI    random access.  See examples/zran.c .
223c9083b85SXin LI
224c9083b85SXin LI29. Does zlib work on MVS, OS/390, CICS, etc.?
225c9083b85SXin LI
226c9083b85SXin LI    It has in the past, but we have not heard of any recent evidence.  There
227c9083b85SXin LI    were working ports of zlib 1.1.4 to MVS, but those links no longer work.
228c9083b85SXin LI    If you know of recent, successful applications of zlib on these operating
229c9083b85SXin LI    systems, please let us know.  Thanks.
230c9083b85SXin LI
231c9083b85SXin LI30. Is there some simpler, easier to read version of inflate I can look at to
232c9083b85SXin LI    understand the deflate format?
233c9083b85SXin LI
234c9083b85SXin LI    First off, you should read RFC 1951.  Second, yes.  Look in zlib's
235c9083b85SXin LI    contrib/puff directory.
236c9083b85SXin LI
237c9083b85SXin LI31. Does zlib infringe on any patents?
238c9083b85SXin LI
239c9083b85SXin LI    As far as we know, no.  In fact, that was originally the whole point behind
240c9083b85SXin LI    zlib.  Look here for some more information:
241c9083b85SXin LI
242*7aa1dba6SXin LI    https://web.archive.org/web/20180729212847/http://www.gzip.org/#faq11
243c9083b85SXin LI
244c9083b85SXin LI32. Can zlib work with greater than 4 GB of data?
245c9083b85SXin LI
246c9083b85SXin LI    Yes.  inflate() and deflate() will process any amount of data correctly.
247c9083b85SXin LI    Each call of inflate() or deflate() is limited to input and output chunks
248c9083b85SXin LI    of the maximum value that can be stored in the compiler's "unsigned int"
249c9083b85SXin LI    type, but there is no limit to the number of chunks.  Note however that the
250c9083b85SXin LI    strm.total_in and strm_total_out counters may be limited to 4 GB.  These
251c9083b85SXin LI    counters are provided as a convenience and are not used internally by
252c9083b85SXin LI    inflate() or deflate().  The application can easily set up its own counters
253c9083b85SXin LI    updated after each call of inflate() or deflate() to count beyond 4 GB.
254c9083b85SXin LI    compress() and uncompress() may be limited to 4 GB, since they operate in a
255c9083b85SXin LI    single call.  gzseek() and gztell() may be limited to 4 GB depending on how
256c9083b85SXin LI    zlib is compiled.  See the zlibCompileFlags() function in zlib.h.
257c9083b85SXin LI
258c9083b85SXin LI    The word "may" appears several times above since there is a 4 GB limit only
259c9083b85SXin LI    if the compiler's "long" type is 32 bits.  If the compiler's "long" type is
260c9083b85SXin LI    64 bits, then the limit is 16 exabytes.
261c9083b85SXin LI
262c9083b85SXin LI33. Does zlib have any security vulnerabilities?
263c9083b85SXin LI
264c9083b85SXin LI    The only one that we are aware of is potentially in gzprintf().  If zlib is
265*7aa1dba6SXin LI    compiled to use sprintf() or vsprintf(), which requires that ZLIB_INSECURE
266*7aa1dba6SXin LI    be defined, then there is no protection against a buffer overflow of an 8K
267*7aa1dba6SXin LI    string space (or other value as set by gzbuffer()), other than the caller
268*7aa1dba6SXin LI    of gzprintf() assuring that the output will not exceed 8K.  On the other
269*7aa1dba6SXin LI    hand, if zlib is compiled to use snprintf() or vsnprintf(), which should
270*7aa1dba6SXin LI    normally be the case, then there is no vulnerability.  The ./configure
271*7aa1dba6SXin LI    script will display warnings if an insecure variation of sprintf() will be
272*7aa1dba6SXin LI    used by gzprintf().  Also the zlibCompileFlags() function will return
273*7aa1dba6SXin LI    information on what variant of sprintf() is used by gzprintf().
274c9083b85SXin LI
275c9083b85SXin LI    If you don't have snprintf() or vsnprintf() and would like one, you can
276*7aa1dba6SXin LI    find a good portable implementation in stb_sprintf.h here:
277c9083b85SXin LI
278*7aa1dba6SXin LI        https://github.com/nothings/stb
279c9083b85SXin LI
280c9083b85SXin LI    Note that you should be using the most recent version of zlib.  Versions
281c9083b85SXin LI    1.1.3 and before were subject to a double-free vulnerability, and versions
282c9083b85SXin LI    1.2.1 and 1.2.2 were subject to an access exception when decompressing
283c9083b85SXin LI    invalid compressed data.
284c9083b85SXin LI
285c9083b85SXin LI34. Is there a Java version of zlib?
286c9083b85SXin LI
287c9083b85SXin LI    Probably what you want is to use zlib in Java. zlib is already included
288c9083b85SXin LI    as part of the Java SDK in the java.util.zip package. If you really want
289c9083b85SXin LI    a version of zlib written in the Java language, look on the zlib home
290*7aa1dba6SXin LI    page for links: https://zlib.net/ .
291c9083b85SXin LI
292c9083b85SXin LI35. I get this or that compiler or source-code scanner warning when I crank it
293c9083b85SXin LI    up to maximally-pedantic. Can't you guys write proper code?
294c9083b85SXin LI
295c9083b85SXin LI    Many years ago, we gave up attempting to avoid warnings on every compiler
296c9083b85SXin LI    in the universe.  It just got to be a waste of time, and some compilers
297c9083b85SXin LI    were downright silly as well as contradicted each other.  So now, we simply
298c9083b85SXin LI    make sure that the code always works.
299c9083b85SXin LI
300c9083b85SXin LI36. Valgrind (or some similar memory access checker) says that deflate is
301c9083b85SXin LI    performing a conditional jump that depends on an uninitialized value.
302c9083b85SXin LI    Isn't that a bug?
303c9083b85SXin LI
304c9083b85SXin LI    No.  That is intentional for performance reasons, and the output of deflate
305c9083b85SXin LI    is not affected.  This only started showing up recently since zlib 1.2.x
306c9083b85SXin LI    uses malloc() by default for allocations, whereas earlier versions used
307c9083b85SXin LI    calloc(), which zeros out the allocated memory.  Even though the code was
308c9083b85SXin LI    correct, versions 1.2.4 and later was changed to not stimulate these
309c9083b85SXin LI    checkers.
310c9083b85SXin LI
311c9083b85SXin LI37. Will zlib read the (insert any ancient or arcane format here) compressed
312c9083b85SXin LI    data format?
313c9083b85SXin LI
314c9083b85SXin LI    Probably not. Look in the comp.compression FAQ for pointers to various
315c9083b85SXin LI    formats and associated software.
316c9083b85SXin LI
317c9083b85SXin LI38. How can I encrypt/decrypt zip files with zlib?
318c9083b85SXin LI
319c9083b85SXin LI    zlib doesn't support encryption.  The original PKZIP encryption is very
320c9083b85SXin LI    weak and can be broken with freely available programs.  To get strong
321*7aa1dba6SXin LI    encryption, use GnuPG, https://www.gnupg.org/ , which already includes zlib
322c9083b85SXin LI    compression.  For PKZIP compatible "encryption", look at
323*7aa1dba6SXin LI    https://infozip.sourceforge.net/
324c9083b85SXin LI
325c9083b85SXin LI39. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?
326c9083b85SXin LI
327c9083b85SXin LI    "gzip" is the gzip format, and "deflate" is the zlib format.  They should
328c9083b85SXin LI    probably have called the second one "zlib" instead to avoid confusion with
329c9083b85SXin LI    the raw deflate compressed data format.  While the HTTP 1.1 RFC 2616
330c9083b85SXin LI    correctly points to the zlib specification in RFC 1950 for the "deflate"
331c9083b85SXin LI    transfer encoding, there have been reports of servers and browsers that
332c9083b85SXin LI    incorrectly produce or expect raw deflate data per the deflate
333c9083b85SXin LI    specification in RFC 1951, most notably Microsoft.  So even though the
334c9083b85SXin LI    "deflate" transfer encoding using the zlib format would be the more
335c9083b85SXin LI    efficient approach (and in fact exactly what the zlib format was designed
336c9083b85SXin LI    for), using the "gzip" transfer encoding is probably more reliable due to
337c9083b85SXin LI    an unfortunate choice of name on the part of the HTTP 1.1 authors.
338c9083b85SXin LI
339c9083b85SXin LI    Bottom line: use the gzip format for HTTP 1.1 encoding.
340c9083b85SXin LI
341c9083b85SXin LI40. Does zlib support the new "Deflate64" format introduced by PKWare?
342c9083b85SXin LI
343c9083b85SXin LI    No.  PKWare has apparently decided to keep that format proprietary, since
344c9083b85SXin LI    they have not documented it as they have previous compression formats.  In
345c9083b85SXin LI    any case, the compression improvements are so modest compared to other more
346c9083b85SXin LI    modern approaches, that it's not worth the effort to implement.
347c9083b85SXin LI
348c9083b85SXin LI41. I'm having a problem with the zip functions in zlib, can you help?
349c9083b85SXin LI
350c9083b85SXin LI    There are no zip functions in zlib.  You are probably using minizip by
351c9083b85SXin LI    Giles Vollant, which is found in the contrib directory of zlib.  It is not
352c9083b85SXin LI    part of zlib.  In fact none of the stuff in contrib is part of zlib.  The
353c9083b85SXin LI    files in there are not supported by the zlib authors.  You need to contact
354c9083b85SXin LI    the authors of the respective contribution for help.
355c9083b85SXin LI
356c9083b85SXin LI42. The match.asm code in contrib is under the GNU General Public License.
357c9083b85SXin LI    Since it's part of zlib, doesn't that mean that all of zlib falls under the
358c9083b85SXin LI    GNU GPL?
359c9083b85SXin LI
360c9083b85SXin LI    No.  The files in contrib are not part of zlib.  They were contributed by
361c9083b85SXin LI    other authors and are provided as a convenience to the user within the zlib
362c9083b85SXin LI    distribution.  Each item in contrib has its own license.
363c9083b85SXin LI
364c9083b85SXin LI43. Is zlib subject to export controls?  What is its ECCN?
365c9083b85SXin LI
366c9083b85SXin LI    zlib is not subject to export controls, and so is classified as EAR99.
367c9083b85SXin LI
368c9083b85SXin LI44. Can you please sign these lengthy legal documents and fax them back to us
369c9083b85SXin LI    so that we can use your software in our product?
370c9083b85SXin LI
371c9083b85SXin LI    No. Go away. Shoo.
372