zlib does not use time_t, so _TIME_BITS is irrelevant. However it
may be defined anyway as part of a sledgehammer indiscriminately
applied to all builds.
Future versions of IBM Z mainframes will provide DFLTCC instruction,
which implements deflate algorithm in hardware with estimated
compression and decompression performance orders of magnitude faster
than the current zlib-ng and ratio comparable with that of level 1.
This patch adds DFLTCC support to zlib-ng. In order to enable it, the
following build commands should be used:
$ ./configure --with-dfltcc-deflate --with-dfltcc-inflate
$ make
When built like this, zlib-ng would compress in hardware on level 1,
and in software on all other levels. Decompression will always happen
in hardware. In order to enable DFLTCC compression for levels 1-6 (i.e.
to make it used by default) one could add -DDFLTCC_LEVEL_MASK=0x7e to
CFLAGS when building zlib-ng.
Two DFLTCC compression calls produce the same results only when they
both are made on machines of the same generation, and when the
respective buffers have the same offset relative to the start of the
page. Therefore care should be taken when using hardware compression
when reproducible results are desired.
DFLTCC does not support every single zlib-ng feature, in particular:
* inflate(Z_BLOCK) and inflate(Z_TREES)
* inflateMark()
* inflatePrime()
* deflateParams() after the first deflate() call
When used, these functions will either switch to software, or, in case
this is not possible, gracefully fail.
This patch tries to add DFLTCC support in a least intrusive way.
All SystemZ-specific code was placed into a separate file, but
unfortunately there is still a noticeable amount of changes in the
main zlib-ng code. Below is the summary of those changes.
DFLTCC takes as arguments a parameter block, an input buffer, an output
buffer and a window. Since DFLTCC requires parameter block to be
doubleword-aligned, and it's reasonable to allocate it alongside
deflate and inflate states, ZALLOC_STATE, ZFREE_STATE and ZCOPY_STATE
macros were introduced in order to encapsulate the allocation details.
The same is true for window, for which ZALLOC_WINDOW and
TRY_FREE_WINDOW macros were introduced.
While for inflate software and hardware window formats match, this is
not the case for deflate. Therefore, deflateSetDictionary and
deflateGetDictionary need special handling, which is triggered using the
new DEFLATE_SET_DICTIONARY_HOOK and DEFLATE_GET_DICTIONARY_HOOK macros.
deflateResetKeep() and inflateResetKeep() now update the DFLTCC
parameter block, which is allocated alongside zlib-ng state, using
the new DEFLATE_RESET_KEEP_HOOK and INFLATE_RESET_KEEP_HOOK macros.
In order to make unsupported deflateParams(), inflatePrime() and
inflateMark() calls to fail gracefully, the new DEFLATE_PARAMS_HOOK,
INFLATE_PRIME_HOOK and INFLATE_MARK_HOOK macros were introduced.
The algorithm implemented in hardware has different compression ratio
than the one implemented in software. In order for deflateBound() to
return the correct results for the hardware implementation, the new
DEFLATE_BOUND_ADJUST_COMPLEN and DEFLATE_NEED_CONSERVATIVE_BOUND macros
were introduced.
Actual compression and decompression are handled by the new DEFLATE_HOOK
and INFLATE_TYPEDO_HOOK macros. Since inflation with DFLTCC manages the
window on its own, calling updatewindow() is suppressed using the new
INFLATE_NEED_UPDATEWINDOW() macro.
In addition to compression, DFLTCC computes CRC-32 and Adler-32
checksums, therefore, whenever it's used, software checksumming needs to
be suppressed using the new DEFLATE_NEED_CHECKSUM and
INFLATE_NEED_CHECKSUM macros.
DFLTCC will refuse to write an End-of-block Symbol if there is no input
data, thus in some cases it is necessary to do this manually. In order
to achieve this, bi_reverse and flush_pending were promoted from static
to ZLIB_INTERNAL and exposed via deflate.h.
Since the first call to dfltcc_inflate already needs the window, and it
might be not allocated yet, inflate_ensure_window was factored out of
updatewindow and made ZLIB_INTERNAL.
zlib-ng/gzlib.c:196:9: warning: implicit declaration of function 'lseek' is invalid in C99 [-Wimplicit-function-declaration]
LSEEK(state->fd, 0, SEEK_END); /* so gzoffset() is correct */
^
zlib-ng/gzlib.c:17:17: note: expanded from macro 'LSEEK'
^
[ 61%] Building C object CMakeFiles/zlibstatic.dir/gzread.c.o
zlib-ng/gzread.c:27:15: warning: implicit declaration of function 'read' is invalid in C99 [-Wimplicit-function-declaration]
ret = read(state->fd, buf + *have, len - *have);
^
zlib-ng/gzread.c:596:11: warning: implicit declaration of function 'close' is invalid in C99 [-Wimplicit-function-declaration]
ret = close(state->fd);
^
[ 62%] Building C object CMakeFiles/zlibstatic.dir/gzwrite.c.o
zlib-ng/gzwrite.c:84:15: warning: implicit declaration of function 'write' is invalid in C99 [-Wimplicit-function-declaration]
got = write(state->fd, strm->next_in, strm->avail_in);
^
zlib-ng/gzwrite.c💯33: warning: implicit declaration of function 'write' is invalid in C99 [-Wimplicit-function-declaration]
if (have && ((got = write(state->fd, state->x.next, (unsigned long)have)) < 0 || (unsigned)got != have)) {
^
zlib-ng/gzwrite.c:512:9: warning: implicit declaration of function 'close' is invalid in C99 [-Wimplicit-function-declaration]
if (close(state->fd) == -1)"
Also add this combination to travis testing.
Remove --native testing from travis, since they somehow make this fail very often,
probably due to caching or running the executables on a different platform than
the compiler thinks it is running on.
to co-exist in an application that has been linked to something that
depends on stock zlib. Previously, that would cause random problems
since there is no way to guarantee what zlib version is being used
for each dynamically linked function.
Add the corresponding zlib-ng.h.
Tests, example and minigzip will not compile before they have been
adapted to use the correct functions as well.
Either duplicate them, so we have minigzip-ng.c for example, or add
compile-time detection in the source code.
* local -> static
* Normalize and cleanup line-endings
* Fix warnings under Visual Studio.
* Whitespace cleanup
***
This patch has been edited to merge cleanly and to exclude type changes.
Based on 8d7a7c3b82c6e38734bd504dac800b148ab410d0 "Type Cleanup"
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.
