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.

You would still need to run zlib2ansi on all of the *.c files.

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.

The function is only available if stdarg.h is available.

 * Use -DASM686=1 to build with i686 asm.
 * Use -DAMD64=1 to build with amd64 asm.

Facilitate multi-platform compilation, e.g.:
nmake -f pathto\zlib\win32\Makefile.msc TOP=pathto\zlib

Mac OS X's linker (derived from LLVM, not GNU binutils) does not support
--version-script. Don't specify it on this platform.

Previously, spaces in ${CMAKE_CURRENT_SOURCE_PATH} would expand into
multiple linker arguments.

Also correct typo for 64-bit debug build.

Suggested by E. Timothy Uy.

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.

Without this fix, it would be possible to construct inputs to puff
that would cause it to segfault.

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.