-29. 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
- 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
- depending on how zlib is compiled.
-
-30. 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.
-
- 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. Can zlib work with greater than 4 GB of data?
+
+ Yes. inflate() and deflate() will process any amount of data correctly.
+ Each call of inflate() or deflate() is limited to input and output chunks
+ of the maximum value that can be stored in the compiler's "unsigned int"
+ type, but there is no limit to the number of chunks. Note however that the
+ strm.total_in and strm_total_out counters may be limited to 4 GB. These
+ counters are provided as a convenience and are not used internally by
+ inflate() or deflate(). 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. gzseek() and gztell() may be limited to 4 GB depending on how
+ zlib is compiled. See the zlibCompileFlags() function in zlib.h.
+
+ The word "may" appears several times above since there is a 4 GB limit only
+ if the compiler's "long" type is 32 bits. If the compiler's "long" type is
+ 64 bits, then the limit is 16 exabytes.
+
+33. 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 an 8K string space (or other value as set by
+ gzbuffer()), other than the caller of gzprintf() assuring that the output
+ will not exceed 8K. On the other 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(). Also the
+ zlibCompileFlags() function will return information on what variant of
+ sprintf() is 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, and versions
+ 1.2.1 and 1.2.2 were subject to an access exception when decompressing
+ invalid compressed data.
+
+34. Is there a Java version of zlib?