Forcing Z_CONST resulted in an issue when compiling Firefox. Now
if someone wants to compile zlib as C++ code (which it isn't), now
they will need to #define Z_CONST themselves.
If the compressed data was already at a block boundary, then
deflateParam() would report Z_BUF_ERROR, because there was nothing
to write. With this patch, Z_OK is returned in that case.
That didn't work when cross-compiling. Simply rely on limits.h.
If a compiler does not have limits.h, then zconf.h.in should be
modified to define Z_U4 as an unsiged four-byte integer type in
order for crc32() to be fast.
This also simplifies and makes more portable to check for a four-
byte type using limits.h.
inftrees.c compared the number of used table entries to the maximum
allowed value using >= instead of >. This patch fixes those to use
>. The bug was discovered by Ignat Kolesnichenko of Yandex LC
where they have run petabytes of data through zlib. Triggering the
bug is apparently very rare, seeing as how it has been out there in
the wild for almost three years before being discovered. The bug
is instantiated only if the exact maximum number of decoding table
entries, ENOUGH_DISTS or ENOUGH_LENS is used by the block being
decoded, resulting in the false positive of overflowing the table.
If the deflateInit2() called for the first gzwrite() failed with a
Z_MEM_ERROR, then a subsequent gzclose() would try to free an
already freed pointer. This fixes that.
A gzopen() to write (mode "w") followed immediately by a gzclose()
would output an empty zero-length file. What it should do is write
an empty gzip file, with the gzip header, empty deflate content,
and gzip trailer totalling 20 bytes. This fixes it to do that.
Avoid the use of an uninitialized value when the write buffers have
not been initialized. A recent change to avoid the use of strm->
next_in in order to resolve some const conflicts added the use of
state->in in its place. This patch avoids the use of state->in
when it is not initialized. Nothing bad would actually happen,
since two variables set to the same unintialized value are
subtracted. However valgrind was rightly complaining. So this
fixes that.
Also clean up comparisons between different types, and some odd
indentation problems that showed up somehow.
A new endless loop was introduced by the clang compiler, which
apparently does odd things when the right operand of << is equal to
or greater than the number of bits in the type. The C standard in
fact states that the behavior of << is undefined in that case. The
loop was rewritten to use single-bit shifts.
