zlib 1.2.0.1
This commit is contained in:
105
FAQ
105
FAQ
@@ -1,5 +1,5 @@
|
||||
|
||||
Frequently Asked Questions about zlib
|
||||
Frequently Asked Questions about zlib
|
||||
|
||||
|
||||
If your question is not there, please check the zlib home page
|
||||
@@ -90,13 +90,14 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html
|
||||
./configure -s
|
||||
make
|
||||
|
||||
14. Why does "make test" fail on Mac OS X?
|
||||
14. How do I install a shared zlib library on Unix?
|
||||
|
||||
Mac OS X already includes zlib as a shared library, and so -lz links the
|
||||
shared library instead of the one that the "make" compiled. The two are
|
||||
incompatible due to different compile-time options. Simply change the -lz
|
||||
in the Makefile to libz.a, and it will use the compiled library instead
|
||||
of the shared one and the "make test" will succeed.
|
||||
make install
|
||||
|
||||
However, many flavors of Unix come with a shared zlib already installed.
|
||||
Before going to the trouble of compiling a shared version of zlib and
|
||||
trying to install it, you may want to check if it's already there! If you
|
||||
can #include <zlib.h>, it's there. The -lz option will probably link to it.
|
||||
|
||||
15. I have a question about OttoPDF
|
||||
|
||||
@@ -108,8 +109,8 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html
|
||||
The compress and deflate functions produce data in the zlib format, which
|
||||
is different and incompatible with the gzip format. The gz* functions in
|
||||
zlib on the other hand use the gzip format. Both the zlib and gzip
|
||||
formats use the same compressed data format, but have different headers
|
||||
and trailers.
|
||||
formats use the same compressed data format internally, but have different
|
||||
headers and trailers around the compressed data.
|
||||
|
||||
17. Ok, so why are there two different formats?
|
||||
|
||||
@@ -127,12 +128,13 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html
|
||||
19. Is zlib thread-safe?
|
||||
|
||||
Yes. However any library routines that zlib uses and any application-
|
||||
provided memory allocation routines must also be thread-safe. Of course,
|
||||
you should only operate on any given zlib or gzip stream from a single
|
||||
thread. zlib's gz* functions use stdio library routines, and most of
|
||||
zlib's functions use the library memory allocation routines by default.
|
||||
zlib's Init functions allow for the application to provide custom memory
|
||||
allocation routines.
|
||||
provided memory allocation routines must also be thread-safe. zlib's gz*
|
||||
functions use stdio library routines, and most of zlib's functions use the
|
||||
library memory allocation routines by default. zlib's Init functions allow
|
||||
for the application to provide custom memory allocation routines.
|
||||
|
||||
Of course, you should only operate on any given zlib or gzip stream from a
|
||||
single thread at a time.
|
||||
|
||||
20. Can I use zlib in my commercial application?
|
||||
|
||||
@@ -142,24 +144,44 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html
|
||||
|
||||
No. Please read the license in zlib.h.
|
||||
|
||||
22. Will zlib work on a big-endian or little-endian architecture, and can I
|
||||
22. The license says that altered source versions must be "plainly marked". So
|
||||
what exactly do I need to do to meet that requirement?
|
||||
|
||||
You need to append something the ZLIB_VERSION string in zlib.h. For
|
||||
example, if the version of the base zlib you are altering is "1.2.3", then
|
||||
you could change the string to "1.2.3-fred-mods-v3". You should not change
|
||||
it to "1.2.4" or "1.2.3.1" since the zlib authors would like to reserve
|
||||
those forms of the version for their own use.
|
||||
|
||||
For altered source distributions, you should also note the origin and
|
||||
nature of the changes in zlib.h, as well as in ChangeLog and README, along
|
||||
with the dates of the alterations. The origin should include at least your
|
||||
name (or your company's name), and an email address to contact for help or
|
||||
issues with the library.
|
||||
|
||||
Note that distributing a compiled zlib library along with zlib.h and
|
||||
zconf.h is also a source distribution, and so you should change
|
||||
ZLIB_VERSION and note the origin and nature of the changes in zlib.h as you
|
||||
would for a full source distribution.
|
||||
|
||||
23. Will zlib work on a big-endian or little-endian architecture, and can I
|
||||
exchange compressed data between them?
|
||||
|
||||
Yes and yes.
|
||||
|
||||
23. Will zlib work on a 64-bit machine?
|
||||
24. Will zlib work on a 64-bit machine?
|
||||
|
||||
It should. It has been tested on 64-bit machines, and has no dependence
|
||||
on any data types being limited to 32-bits in length. If you have any
|
||||
difficulties, please provide a complete problem report to zlib@gzip.org
|
||||
|
||||
24. Will zlib decompress data from the PKWare Data Compression Library?
|
||||
25. Will zlib decompress data from the PKWare Data Compression Library?
|
||||
|
||||
No. The PKWare DCL uses a completely different compressed data format
|
||||
than does PKZIP and zlib. However, you can look in zlib's contrib/blast
|
||||
directory for a possible solution to your problem.
|
||||
|
||||
25. Can I access data randomly in a compressed stream?
|
||||
26. Can I access data randomly in a compressed stream?
|
||||
|
||||
No, not without some preparation. If when compressing you periodically
|
||||
use Z_FULL_FLUSH, carefully write all the pending data at those points,
|
||||
@@ -167,76 +189,83 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html
|
||||
at those points. You have to be careful to not use Z_FULL_FLUSH too
|
||||
often, since it can significantly degrade compression.
|
||||
|
||||
26. Does zlib work on MVS, OS/390, CICS, etc.?
|
||||
27. Does zlib work on MVS, OS/390, CICS, etc.?
|
||||
|
||||
We don't know for sure. We have heard occasional reports of success on
|
||||
these systems. If you do use it on one of these, please provide us with
|
||||
a report, instructions, and patches that we can reference when we get
|
||||
these questions. Thanks.
|
||||
|
||||
27. Is there some simpler, easier to read version of inflate I can look at
|
||||
28. Is there some simpler, easier to read version of inflate I can look at
|
||||
to understand the deflate format?
|
||||
|
||||
First off, you should read RFC 1951. Second, yes. Look in zlib's
|
||||
contrib/puff directory.
|
||||
|
||||
28. Does zlib infringe on any patents?
|
||||
29. Does zlib infringe on any patents?
|
||||
|
||||
As far as we know, no. In fact, that was originally the whole point behind
|
||||
zlib. Look here for some more information:
|
||||
|
||||
http://www.gzip.org/#faq11
|
||||
|
||||
29. Can zlib work with greater than 4 GB of data?
|
||||
30. Can zlib work with greater than 4 GB of data?
|
||||
|
||||
Yes. inflate() and deflate() will process any amount of data correctly.
|
||||
However the strm.total_in and strm_total_out counters may be limited to
|
||||
4 GB. The user can easily set up their own counters updated after each
|
||||
4 GB. The application can easily set up its own counters updated after each
|
||||
call of inflate() or deflate() to count beyond 4 GB. compress() and
|
||||
uncompress() may be limited to 4 GB, since they operate in a single
|
||||
call using unsigned long lengths. gzseek() may be limited to 4 GB
|
||||
uncompress() may be limited to 4 GB, since they operate in a single call
|
||||
using unsigned long lengths. gzseek() and gztell() may be limited to 4 GB
|
||||
depending on how zlib is compiled.
|
||||
|
||||
30. Does zlib have any security vulnerabilities?
|
||||
31. Does zlib have any security vulnerabilities?
|
||||
|
||||
The only one that we are aware of is potentially in gzprintf(). If zlib
|
||||
is compiled to use sprintf() or vsprintf(), then there is no protection
|
||||
against a buffer overflow of a 4K string space, other than the caller of
|
||||
gzprintf() assuring that the output will not exceed 4K. On the other
|
||||
hand, if zlib is compiled to use snprintf() or vsnprintf(), then there is
|
||||
no vulnerability.
|
||||
hand, if zlib is compiled to use snprintf() or vsnprintf(), which should
|
||||
normally be the case, then there is no vulnerability. The ./configure
|
||||
script will display warnings if an insecure variation of sprintf() will
|
||||
be used by gzprintf().
|
||||
|
||||
If you don't have snprintf() or vsnprintf() and would like one, you can
|
||||
find a portable implementation here:
|
||||
|
||||
http://www.ijs.si/software/snprintf/
|
||||
|
||||
Note that you should be using the most recent version of zlib. Versions
|
||||
1.1.3 and before were subject to a double-free vulnerability.
|
||||
|
||||
31. Is there a Java version of zlib?
|
||||
32. Is there a Java version of zlib?
|
||||
|
||||
Probably what you want is to use zlib in Java. zlib is already included
|
||||
as part of the Java SDK in the java.util.zip class. If you really want
|
||||
a version of zlib written in the Java language, look on the zlib home
|
||||
page for links: http://www.zlib.org/
|
||||
|
||||
32. I get this or that compiler or source-code scanner warning. Can't you guys
|
||||
write proper code?
|
||||
33. I get this or that compiler or source-code scanner warning when I crank it
|
||||
up to maximally-pendantic. Can't you guys write proper code?
|
||||
|
||||
Many years ago, we gave up attempting to avoid warnings on every compiler
|
||||
in the universe. It just got to be a waste of time, and some compilers
|
||||
were downright silly. So now, we simply make sure that the code always
|
||||
works.
|
||||
|
||||
33. Will zlib read the (insert any ancient or arcane format here) compressed
|
||||
34. Will zlib read the (insert any ancient or arcane format here) compressed
|
||||
data format?
|
||||
|
||||
Probably not. Look in the comp.compression FAQ for pointers to various
|
||||
formats and associated software.
|
||||
|
||||
34. How can I encrypt/decrypt zip files with zlib?
|
||||
35. How can I encrypt/decrypt zip files with zlib?
|
||||
|
||||
zlib doesn't support encryption. PKZIP encryption is very weak and can be
|
||||
broken with freely available programs. To get strong encryption, use gpg
|
||||
which already includes zlib compression.
|
||||
|
||||
35. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?
|
||||
36. What's the difference between the "gzip" and "deflate" HTTP 1.1 encodings?
|
||||
|
||||
"gzip" is the gzip format, and "deflate" is the zlib format. They should
|
||||
probably have called the second one "zlib" instead to avoid confusion
|
||||
@@ -250,14 +279,14 @@ The lastest zlib FAQ is at http://www.gzip.org/zlib/zlib_faq.html
|
||||
for), using the "gzip" transfer encoding is probably more reliable due to
|
||||
an unfortunate choice of name on the part of the HTTP 1.1 authors.
|
||||
|
||||
36. Does zlib support the new "Deflate64" format introduced by PKWare?
|
||||
37. Does zlib support the new "Deflate64" format introduced by PKWare?
|
||||
|
||||
No. PKWare has apparently decided to keep that format proprietary, since
|
||||
they have not documented it as they have previous compression formats.
|
||||
In any case, the compression improvements are so modest compared to other
|
||||
more modern approaches, that it's not worth the effort to implement.
|
||||
|
||||
37. Can you please sign these lengthy legal documents and fax them back to us
|
||||
38. Can you please sign these lengthy legal documents and fax them back to us
|
||||
so that we can use your software in our product?
|
||||
|
||||
No.
|
||||
No. Go away.
|
||||
|
||||
Reference in New Issue
Block a user