-
Notifications
You must be signed in to change notification settings - Fork 2.5k
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
Showing
71 changed files
with
10,334 additions
and
4,007 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -1,5 +1,29 @@ | ||
|
|
||
| ChangeLog file for zlib | ||
| ChangeLog file for zlib | ||
| Changes in 1.2.0.1 (17 March 2003) | ||
| - Add Z_RLE strategy for run-length encoding [Truta] | ||
| - When Z_RLE requested, restrict matches to distance one | ||
| - Update zlib.h, minigzip.c, gzopen(), gzdopen() for Z_RLE | ||
| - Correct FASTEST compilation to allow level == 0 | ||
| - Clean up what gets compiled for FASTEST | ||
| - Incorporate changes to zconf.in.h [Vollant] | ||
| - Refine detection of Turbo C need for dummy returns | ||
| - Refine ZLIB_DLL compilation | ||
| - Include additional header file on VMS for off_t typedef | ||
| - Try to use _vsnprintf where it supplants vsprintf [Vollant] | ||
| - Add some casts in inffast.c | ||
| - Enchance comments in zlib.h on what happens if the gzprintf() tries to | ||
| write more than 4095 bytes before compression | ||
| - Remove unused state from inflateBackEnd() | ||
| - Remove exit(0) from minigzip.c, example.c | ||
| - Get rid of all those darn tabs | ||
| - Add "check" target to Makefile.in that does the same thing as "test" | ||
| - Add "mostlyclean" and "maintainer-clean" targets to Makefile.in | ||
| - Update contrib/inflate86 [Anderson] | ||
| - Update contrib/testzlib, contrib/vstudio, contrib/minizip [Vollant] | ||
| - Add msdos and win32 directories with makefiles [Truta] | ||
| - More additions and improvements to the FAQ | ||
|
|
||
| Changes in 1.2.0 (9 March 2003) | ||
| - New and improved inflate code | ||
| - About 20% faster | ||
|
|
@@ -236,13 +260,13 @@ Changes in 1.0.6 (19 Jan 1998) | |
| - added Makefile.nt (thanks to Stephen Williams) | ||
| - added the unsupported "contrib" directory: | ||
| contrib/asm386/ by Gilles Vollant <[email protected]> | ||
| 386 asm code replacing longest_match(). | ||
| 386 asm code replacing longest_match(). | ||
| contrib/iostream/ by Kevin Ruland <[email protected]> | ||
| A C++ I/O streams interface to the zlib gz* functions | ||
| contrib/iostream2/ by Tyge L�vset <[email protected]> | ||
| Another C++ I/O streams interface | ||
| Another C++ I/O streams interface | ||
| contrib/untgz/ by "Pedro A. Aranda Guti\irrez" <[email protected]> | ||
| A very simple tar.gz file extractor using zlib | ||
| A very simple tar.gz file extractor using zlib | ||
| contrib/visual-basic.txt by Carlos Rios <[email protected]> | ||
| How to use compress(), uncompress() and the gz* functions from VB. | ||
| - pass params -f (filtered data), -h (huffman only), -1 to -9 (compression | ||
|
|
@@ -269,7 +293,7 @@ Changes in 1.0.6 (19 Jan 1998) | |
| - add NEED_DUMMY_RETURN for Borland | ||
| - use variable z_verbose for tracing in debug mode (L. Peter Deutsch). | ||
| - allow compilation with CC | ||
| - defined STDC for OS/2 (David Charlap) | ||
| - defined STDC for OS/2 (David Charlap) | ||
| - limit external names to 8 chars for MVS (Thomas Lund) | ||
| - in minigzip.c, use static buffers only for 16-bit systems | ||
| - fix suffix check for "minigzip -d foo.gz" | ||
|
|
||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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,101 +144,128 @@ 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 [email protected] | ||
|
|
||
| 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, | ||
| and keep an index of those locations, then you can start decompression | ||
| 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. | ||
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.