More than a decade later, Microsoft C does not support the C99
standard. It's good that _snprintf has a different name, since it
does not guarantee that the result is null terminated, as does
snprintf. However where _snprintf is used under Microsoft C, the
destination string is assured to be long enough, so this will not
be a problem. This occurs in two places, both in gzlib.c. Where
sprintf functionality is needed by gzprintf, vsnprintf is used in
the case of Microsoft C.
This avoids warnings in OpenBSD that apparently can't be turned
off whenever you link strcpy, strcat, or sprintf. When snprintf
isn't available, the use of the "unsafe" string functions has
always in fact been safe, since the lengths are all checked before
those functions are called.
We do not use strlcpy or strlcat, since they are not (yet) found on
all systems. snprintf on the other hand is part of the C standard
library and is very common.
crc_table is made using a four-byte integer (when that can be
determined). However get_crc_table() returned a pointer to an
unsigned long, which could be eight bytes. This fixes that by
creating a new z_crc_t type for the crc_table.
This type is also used for the BYFOUR crc calculations that depend
on a four-byte type. The four-byte type can now be determined by
./configure, which also solves a problem where ./configure --solo
would never use BYFOUR. No the Z_U4 #define indicates that four-
byte integer was found either by ./configure or by zconf.h.
The conversion to multi-byte will be locale-specific, but it's
better than nothing and is only to provide more information in the
error message returned by gz_error(). The conversion has no
effect on what's opened.
Also need to #include <stddef.h> for zlib.h, and need to workaround
the inability to use wide characters in constructed error messages
with zlib's interface.
