fix bug #289: use strcpy instead of strncpy

to avoid a GCC 8 warning:

test/example.c:465:48: warning: argument to ‘sizeof’ in ‘strncpy’ call is the same expression as the source; did you mean to use the size of the destination? [-Wsizeof-pointer-memaccess]
     strncpy((char*)uncompr, garbage_str, sizeof(garbage_str));

fix bug #208: let the compiler generate code for unaligned stores

to avoid this error:
zlib-ng/arch/x86/deflate_quick.c:154:5: runtime error: store to misaligned address 0x631000014801 for type 'unsigned int', which requires 4 byte alignment
0x631000014801: note: pointer points here
00 80 02  d3 07 00 00 be be be be  be be be be be be be be  be be be be be be be be  be be be be be
               ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior zlib-ng/arch/x86/deflate_quick.c:154:5 in

fix bug #225: account bits sent

clean up logic of configure and make for sanitizer flags

cleanup configure output for checking the compiler

cleanup configure output by using echo -n

only check for -mfpu=neon on ARM processors

cleanup multiple test -o expressions by using case

This patch fixes a problem with detecting the target that gcc compiles for when
using -m32.  The error is in the way we detect GCC_ARCH in configure:

GCC_ARCH=`$CC $CFLAGS -dumpmachine | sed 's/-.*//g'`

Here is the output of gcc and clang:

$ gcc  -m32 -std=c99 -dumpmachine
x86_64-linux-gnu

$ clang  -m32 -std=c99 -dumpmachine
i386-pc-linux-gnu

It looks like it is a known problem:
https://gcc.gnu.org/ml/gcc-help/2018-05/msg00053.html This patch checks whether
the compiler has the flag -print-multiarch in which case it uses it instead of
-dumpmachine to print the compiler target:

$ gcc -print-multiarch
x86_64-linux-gnu
$ gcc -print-multiarch -m32
i386-linux-gnu
$ clang -print-multiarch
clang: error: unknown argument: '-print-multiarch'

There were a few places that used an explicit test for i686 that are now also
checking for i386 as this is the value set in ARCH for gcc and clang when
configuring zlib-ng with --32.

remove -DX86

remove unused compilation flag -DX86_64

bug #266: select std2 for gcc/clang ARM 32-bit builds

Running the Chromium zlib benchmark tool on a Hikey 970 device
showed uplifts for both gcc and clang when using std2 (larger is
better):

arm_h02_std3_gcc_0ca47588bd2e38/score.out  =  7.964881
arm_h02_std3_llvm_2e8efbb084ae87/score.out =  9.522024
arm_h02_std1_gcc_0ca47588bd2e38/score.out  =  9.641071
arm_h02_std2_gcc_0ca47588bd2e38/score.out  =  9.919345
arm_h02_std1_llvm_2e8efbb084ae87/score.out =  9.925893
arm_h02_std2_llvm_2e8efbb084ae87/score.out = 10.049107

remove unused variable

remove unused variables

COMP: Fix missing header unistd.h

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:100: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)"

Let deflate_medium be enabled by default.

Replace the UNROLL_LESS define with UNROLL_MORE, making UNROLL_LESS the default.
Performance benchmarks have so far not shown that any platform benefits from UNROLL_MORE,
although this might be beneficial on older compilers/cpus or for compiling without optimizations.

The extra UNROLL_MORE code should be considered for removal since it is never enabled by us
and will likely only serve to confuse and contribute to bitrot.

fix warning with configure --debug

arch/x86/deflate_quick.c:184:21: warning: format ‘%u’ expects argument of type ‘unsigned int’, but argument 5 has type ‘size_t {aka long unsigned int}’ [-Wformat=]

ENH: Remove superflous setting for cmake 2.6.0+

As of CMake 2.6.0 the ELSE() and ENDIF() constructs can be empty. The
same is true for closing constructs on ENDMACRO(), ENDFUNCTION(), and
ENDFOREACH().

If you require 2.4.x compatibility, CMake 2.4.3 or greater
recognizes the CMAKE_ALLOW_LOOSE_LOOP_CONSTRUCTS option (which is
superfluous in 2.6.0)

typedef ptrdiff_t when stddef.h does not provide it

Fix win32 makefiles to no longer attempt to build match.obj.
Both of these makefiles should get their dependency maps
regenerated, since they seem to be very outdated.

mark longest_match static inline

x86_64-linux compiled with clang and gcc at -O3 shows that inlining
longest_match() brings good speedup overall with speedups of up to 8%.
clang https://gist.github.com/sebpop/17d9c340cfaf16c1854017efefce6fc3
gcc https://gist.github.com/sebpop/451160356fc4e73541a1b8eef7dceb97

performance is also better on aarch64-linux with speedups up to 3.5%.
clang https://gist.github.com/sebpop/aec3e068a61c1daddf9c72ab4bc33281
gcc https://gist.github.com/sebpop/f0d4e6bfd58d95b313c955b5d747a74f

move match.c to match_p.h and remove match.h

Add scan-build cmake build to build matrix

Update travis to xenial

fix bug #263: hoist invariant loads

This patch speeds up longest_match when compiled with clang for x86_64 to match
the performance of zlib.org. The performance of zlib-ng does not change much
when compiled with gcc for x86_64, or when zlib-ng is cross compiled by gcc or
llvm for aarch64.

Performance analysis for this patch:
https://gist.github.com/sebpop/7cdc5b2abd3297c5fcd2a8315bd9a209

Limit hash table inserts after switch from stored deflate.

This limits hash table inserts to the available data in the window
and to the sliding window size in deflate_stored(). The hash table
inserts are deferred until deflateParams() switches to a non-zero
compression level.

Small speedup to inflate [psumbera].

Seeing a few percent speedup by using a pointer instead of an
assigned structure. This seems to help the compiler to optimize
better.

fix configure for arm cross compilation

configure used to end with ARCH=x86_64 even when using a cross compiler
targeting arm. When using a compiler targeting aarch64 there was no problem
detecting a correct ARCH.

Permit a deflateParams() parameter change as soon as possible.

This commit allows a parameter change even if the input data has
not all been compressed and copied to the application output
buffer, so long as all of the input data has been compressed to
the internal pending output buffer. This also allows an immediate
deflateParams change so long as there have been no deflate calls
since initialization or reset.

Fix bug when window full in deflate_stored().

Fix CLEAR_HASH macro to be usable as a single statement.

As it is used in deflateParams().

Avoid a conversion error in gzseek when off_t type too small.

This is a problem in the odd case that the second argument of
LSEEK is a larger type than off_t. Apparently MinGW defines off_t
to be 32 bits, but _lseeki64 has a 64-bit second argument.

Also undo a previous commit to permit MinGW to use _lseeki64.

Have Makefile return non-zero error code on test failure.

Avoid some conversion warnings in gzread.c and gzwrite.c.

Return an error if the gzputs string length can't fit in an int.

Don't compute check value for raw inflate if asked to validate.

fix several memory sanitizer errors on aarch64

With this patch we have a clean run of make test on aarch64 when zlib-ng is
configured with --with-msan --with-fuzzers.

remove unused configure check for HAVE_STDARG_H

Fix compilation with --solo and --debug combined.

However this ends up not really being solo, since it has to
include external libraries.

avoid double definitions for LITTLE_ENDIAN and BYTE_ORDER

When compiling with `cmake; make` the compiler used to warn about double
definitions:

../gzendian.h:11:0: warning: "LITTLE_ENDIAN" redefined
 #  define LITTLE_ENDIAN __ORDER_LITTLE_ENDIAN__
 ^
In file included from /usr/include/x86_64-linux-gnu/bits/string2.h:51:0,
                 from /usr/include/string.h:630,
                 from ../zutil.h:24,
                 from ../deflate.h:15,
                 from ../functable.h:9,
                 from ../functable.c:7:
/usr/include/endian.h:45:0: note: this is the location of the previous definition
 # define LITTLE_ENDIAN __LITTLE_ENDIAN
 ^
In file included from ../deflate.h:16:0,
                 from ../functable.h:9,
                 from ../functable.c:7:
../gzendian.h:12:0: warning: "BYTE_ORDER" redefined
 #  define BYTE_ORDER LITTLE_ENDIAN
 ^
In file included from /usr/include/x86_64-linux-gnu/bits/string2.h:51:0,
                 from /usr/include/string.h:630,
                 from ../zutil.h:24,
                 from ../deflate.h:15,
                 from ../functable.h:9,
                 from ../functable.c:7:
/usr/include/endian.h:48:0: note: this is the location of the previous definition
 # define BYTE_ORDER __BYTE_ORDER
 ^

Cygwin does not have _wopen(), so do not create gzopen_w() there.

remove `unaligned store` UBsan warnings

This patch addresses several warnings from `make test` when
zlib-ng was configured -with-fuzzers -with-sanitizers:

zlib-ng/trees.c:798:5: runtime error: store to misaligned address 0x63100125c801 for type 'uint16_t' (aka 'unsigned short'), which requires 2 byte alignment
0x63100125c801: note: pointer points here
 00 80 76  01 8b 08 00 00 00 00 00  00 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00
              ^
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior zlib-ng/trees.c:798:5 in
zlib-ng/trees.c:799:5: runtime error: store to misaligned address 0x63100125c803 for type 'uint16_t' (aka 'unsigned short'), which requires 2 byte alignment
0x63100125c803: note: pointer points here
 76  01 f5 08 00 00 00 00 00  00 03 00 00 00 00 00 00  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00
              ^

Instead of using `*(uint16_t*) foo = bar` to write a uint16_t, call
__builtin_memcpy which will be safe in case of memory page boundaries.

Without the patch:

 Performance counter stats for './minigzip -9 llvm.tar':

      13173.840115      task-clock (msec)         #    1.000 CPUs utilized
                27      context-switches          #    0.002 K/sec
                 0      cpu-migrations            #    0.000 K/sec
               129      page-faults               #    0.010 K/sec
    57,801,072,298      cycles                    #    4.388 GHz
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
    75,270,723,557      instructions              #    1.30  insns per cycle
    17,797,368,302      branches                  # 1350.963 M/sec
       196,795,107      branch-misses             #    1.11% of all branches

      13.177897531 seconds time elapsed

45408 -rw-rw-r-- 1 spop spop 46493896 Dec 11 14:45 llvm.tar.gz

With remove-unaligned-stores patch:

      13184.736536      task-clock (msec)         #    1.000 CPUs utilized
                44      context-switches          #    0.003 K/sec
                 1      cpu-migrations            #    0.000 K/sec
               129      page-faults               #    0.010 K/sec
    57,882,724,316      cycles                    #    4.390 GHz
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
    75,235,920,853      instructions              #    1.30  insns per cycle
    17,826,873,999      branches                  # 1352.084 M/sec
       196,050,096      branch-misses             #    1.10% of all branches

      13.185868238 seconds time elapsed

45408 -rw-rw-r-- 1 spop spop 46493896 Dec 11 14:46 llvm.tar.gz

bug #117: speed up inflate_fast

Based on a patch by Nigel Tao:
https://github.com/madler/zlib/pull/292/commits/e0ff1f330cc03ee04843f857869b4036593ab39d

This patch makes unzipping of files up to 1.2x faster on x86_64.  The other part
(1.3x speedup) of the patch by Nigel Tao is unsafe as discussed in the review of
that pull request.  zlib-ng already has a different way to optimize the memcpy
for that missing part.

The original patch was enabled only on little-endian machines. This patch adapts
the loading of 64 bits at a time to big endian machines.

Benchmarking notes from Hans Kristian Rosbach:
https://github.com/zlib-ng/zlib-ng/pull/224#issuecomment-444837182

Benchmark runs: 7, tested levels: 0-7, testfile 100M

develop at 796ad10 with -O3:
Level  Comp   Comptime min/avg/max  Decomptime min/avg/max
0     100.02%       0.01/0.01/0.02          0.08/0.09/0.11
1      47.08%       0.49/0.50/0.51          0.37/0.39/0.40
2      36.02%       1.10/1.12/1.13          0.39/0.39/0.40
3      34.77%       1.32/1.34/1.37          0.38/0.38/0.38
4      33.41%       1.50/1.53/1.56          0.37/0.37/0.38
5      33.07%       1.85/1.87/1.90          0.36/0.37/0.38
6      32.83%       2.54/2.57/2.61          0.36/0.37/0.38
avg    45.31%                 1.28                   0.34
tot                          62.60                  16.58

PR224 with -O3:
Level  Comp   Comptime min/avg/max  Decomptime min/avg/max
0     100.02%       0.01/0.01/0.02          0.09/0.09/0.10
1      47.08%       0.49/0.50/0.51          0.37/0.37/0.38
2      36.02%       1.09/1.11/1.13          0.38/0.38/0.39
3      34.77%       1.32/1.34/1.38          0.35/0.36/0.38
4      33.41%       1.49/1.52/1.54          0.36/0.36/0.37
5      33.07%       1.85/1.88/1.93          0.35/0.36/0.37
6      32.83%       2.55/2.58/2.65          0.35/0.35/0.36
avg    45.31%                 1.28                   0.33
tot                          62.48                  16.02

So I see about a 5.4% speedup on my x86_64 machine, not quite the 1.2x speedup
but a nice speedup nevertheless. This benchmark measures the total execution
time of minigzip, so that might have caused some inefficiencies.

At -O2, I only see a 2.7% speedup.

Emphasize the need to continue decompressing gzip members.

Also in zlib-ng.h.

Add Buildkite status badge

Fix Travis badge
Update readme file

Avoid undefined behaviors of memcpy() in gz*printf().

Make the names in functions declarations identical to definitions.

Assure that the number of bits for deflatePrime() is valid.

Handle case where inflateSync used when header never processed.

If zlib and/or gzip header processing was requested, but a header
was never provided and inflateSync was used successfully, then the
inflate state would be inconsistent, trying to compute a check
value but with no flags set. This commit sets the inflate mode to
raw in this case, since there is no other assumption that can be
made if a header was requested but never seen.

Zlib patch: prevent uninitialized use of state->check

This CL fixes a security bug in zlib. It was reported upstream long ago
and the testcase was shared upstream but it's yet unsolved. As a fix,
state->check is set to the same value as the adler32 of an empty string.

Upstream bug: madler/zlib#245

Bug: chromium:697481 https://crbug.com/697481
Reviewed-on: https://chromium-review.googlesource.com/601193
Reviewed-by: Tom Sepez <tsepez@chromium.org>
Reviewed-by: Adam Langley <agl@chromium.org>
Commit-Queue: Nicolás Peña <npm@chromium.org>

return an index for hash map collisions in insert_string

The current version of insert_string_c and variations for sse2, arm, and aarch64
in zlib-ng has changed semantics from the original code of INSERT_STRING macro
in zlib:

 #define INSERT_STRING(s, str, match_head) \
   (UPDATE_HASH(s, s->ins_h, s->window[(str) + (MIN_MATCH-1)]), \
    match_head = s->prev[(str) & s->w_mask] = s->head[s->ins_h], \
    s->head[s->ins_h] = (Pos)(str))

The code of INSERT_STRING assigns match_head with the content of s->head[s->ins_h].

In zlib-ng, the assignment to match_head happens in the caller of insert_string().
zlib-ng's insert_string_*() functions return 0 instead of str+idx in case of
collision, i.e., when if (s->head[s->ins_h] == str+idx).

The effect of returning 0 instead of the content of s->head[s->ins_h] is that
the search for a longest_match through s->prev[] chains will be cut short when
arriving at 0. This leads to a shorter compression time at the expense of a
worse compression rate: returning 0 cuts out the search space.

With this patch:

 Performance counter stats for './minigzip -9 llvm.tar':

      13422.379017      task-clock (msec)         #    1.000 CPUs utilized
                20      context-switches          #    0.001 K/sec
                 0      cpu-migrations            #    0.000 K/sec
               130      page-faults               #    0.010 K/sec
    58,926,104,511      cycles                    #    4.390 GHz
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
    77,543,740,646      instructions              #    1.32  insns per cycle
    17,158,892,214      branches                  # 1278.379 M/sec
       198,433,680      branch-misses             #    1.16% of all branches

      13.423365095 seconds time elapsed

45408 -rw-rw-r-- 1 spop spop 46493896 Dec 11 11:47 llvm.tar.gz

Without this patch the compressed file is larger:

 Performance counter stats for './minigzip -9 llvm.tar':

      13459.342312      task-clock (msec)         #    1.000 CPUs utilized
                25      context-switches          #    0.002 K/sec
                 0      cpu-migrations            #    0.000 K/sec
               129      page-faults               #    0.010 K/sec
    59,088,391,808      cycles                    #    4.390 GHz
   <not supported>      stalled-cycles-frontend
   <not supported>      stalled-cycles-backend
    77,600,766,958      instructions              #    1.31  insns per cycle
    17,486,130,785      branches                  # 1299.182 M/sec
       196,281,761      branch-misses             #    1.12% of all branches

      13.463512830 seconds time elapsed

45408 -rw-rw-r-- 1 spop spop 46493896 Dec 11 11:48 llvm.tar.gz

Correct the initialization requirements for deflateInit2().

fix bug #210: split statement in two to avoid substract overflow

make check used to fail with:
trees.c:482:53: runtime error: unsigned integer overflow: 6 - 7 cannot be represented in type 'unsigned int'
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior trees.c:482:53 in

Patch from Mika Lindqvist.

Add legal disclaimer to README.

Emphasize the need to continue decompressing gzip members.

check endianness of target architecture with preprocessor

move MEMCPY and MEMSET to zutil.h

define ZSWAP64 and ZSWAP16

Add definition of ZSWAP64 and ZSWAP16 in the same place as ZSWAP32.

Move "-O2" compiler flag before CFLAGS from environment, this ensures
CFLAGS can properly override the optimizer flag.

[ARM/AArch64] Add run-time detection of ACLE and NEON instructions under Linux.
* Use getauxval() to check support for ACLE CRC32 instructions
* Allow disabling CRC32 instruction check

remove build warning about 'fdopen'

zlib-ng/test/fuzz/minigzip_fuzzer.c:153:31: warning: implicit declaration of function 'fdopen' is invalid in C99 [-Wimplicit-function-declaration]
    gz->file = path == NULL ? fdopen(fd, gz->write ? "wb" : "rb") :
                              ^
zlib-ng/test/fuzz/minigzip_fuzzer.c:153:29: warning: pointer/integer type mismatch in conditional expression ('int' and 'FILE *' (aka 'struct _IO_FILE *'))
      [-Wconditional-type-mismatch]
    gz->file = path == NULL ? fdopen(fd, gz->write ? "wb" : "rb") :
                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

make fuzzer-test fail on first error

add test/fuzz for fast crc32

Add crc32_combine_gen() and crc32_combine_op() for fast combines.

When the same len2 is used repeatedly, it is faster to use
crc32_combine_gen() to generate an operator, that is then used to
combine CRCs with crc32_combine_op().

Add tables for crc32_combine(), to speed it up by a factor of 200.

- Fix string concatenation failing in configure, causing it to compile without optimizations by default.
- Change default optimization level in configure to -O2, same as in cmake.
- Remove unused variable "cflags".

remove 16-byte alignment from deflate_state::crc0

We noticed recently on the Skia tree that if we build Chromium's zlib
with GCC, -O3, -m32, and -msse2, deflateInit2_() crashes.  Might also
need -fPIC... not sure.

I tracked this down to a `movaps` (16-byte aligned store) to an address
that was only 8-byte aligned.  This address was somewhere in the middle
of the deflate_state struct that deflateInit2_()'s job is to initialize.

That deflate_state struct `s` is allocated using ZALLOC, which calls any
user supplied zalloc if set, or the default if not.  Neither one of
these has any special alignment contract, so generally they'll tend to
be 2*sizeof(void*) aligned.  On 32-bit builds, that's 8-byte aligned.

But because we've annotated crc0 as zalign(16), the natural alignment of
the whole struct is 16-byte, and a compiler like GCC can feel free to
use 16-byte aligned stores to parts of the struct that are 16-byte
aligned, like the beginning, crc0, or any other part before or after
crc0 that happens to fall on a 16-byte boundary.  With -O3 and -msse2,
GCC does exactly that, writing a few of the fields with one 16-byte
store.

The fix is simply to remove zalign(16).  All the code that manipulates
this field was actually already using unaligned loads and stores.  You
can see it all right at the top of crc_folding.c, CRC_LOAD and CRC_SAVE.

This bug comes from the Intel performance patches we landed a few years
ago, and isn't present in upstream zlib, Android's zlib, or Google's
internal zlib.

It doesn't seem to be tickled by Clang, and won't happen on 64-bit GCC
builds: zalloc is likely 16-byte aligned there.  I _think_ it's possible
for it to trigger on non-x86 32-bit builds with GCC, but haven't tested
that.  I also have not tested MSVC.

Reviewed-on: https://chromium-review.googlesource.com/1236613

Fix a bug that can crash deflate on some input when using Z_FIXED.

This bug was reported by Danilo Ramos of Eideticom, Inc. It has
lain in wait 13 years before being found! The bug was introduced
in zlib 1.2.2.2, with the addition of the Z_FIXED option. That
option forces the use of fixed Huffman codes. For rare inputs with
a large number of distant matches, the pending buffer into which
the compressed data is written can overwrite the distance symbol
table which it overlays. That results in corrupted output due to
invalid distances, and can result in out-of-bound accesses,
crashing the application.

The fix here combines the distance buffer and literal/length
buffers into a single symbol buffer. Now three bytes of pending
buffer space are opened up for each literal or length/distance
pair consumed, instead of the previous two bytes. This assures
that the pending buffer cannot overwrite the symbol table, since
the maximum fixed code compressed length/distance is 31 bits, and
since there are four bytes of pending space for every three bytes
of symbol space.

fix oss-fuzz/11323: clear out s->prev buffer

zlib-ng compiled with MSAN used to fail with:

SUMMARY: MemorySanitizer: use-of-uninitialized-value /src/zlib-ng/match.c:473:60 in longest_match
Exiting

  Uninitialized value was stored to memory at
    #0 0x7fcaced77645 in fill_window_sse /src/zlib-ng/arch/x86/fill_window_sse.c:84:17
    #1 0x7fcaced7d3d4 in deflate_quick /src/zlib-ng/arch/x86/deflate_quick.c:230:13
    #2 0x7fcaced2f54b in zng_deflate /src/zlib-ng/deflate.c:951:18
    #3 0x4a04e9 in test_large_deflate /src/zlib-ng/test/example.c:266:11
    #4 0x4a38d2 in main /src/zlib-ng/test/example.c:539:5
    #5 0x7fcace96a82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

  Uninitialized value was created by a heap allocation
    #0 0x45bf70 in malloc /src/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:910
    #1 0x7fcaced26cd9 in zng_deflateInit2_ /src/zlib-ng/deflate.c:315:26
    #2 0x7fcaced2605a in zng_deflateInit_ /src/zlib-ng/deflate.c:224:12
    #3 0x4a03c5 in test_large_deflate /src/zlib-ng/test/example.c:255:11
    #4 0x4a38d2 in main /src/zlib-ng/test/example.c:539:5
    #5 0x7fcace96a82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)

fix bug #215: use the proper intrinsic __crc32w for words (#217)

integration of oss-fuzz in make test #204 (#206)

The requirements for an ideal integration of a project in oss-fuzz are:
https://github.com/google/oss-fuzz/blob/master/docs/ideal_integration.md
- Is maintained by code owners in their RCS (Git, SVN, etc).
- Is built with the rest of the tests - no bit rot!
- Has a seed corpus with good code coverage.
- Is continuously tested on the seed corpus with ASan/UBSan/MSan
- Is fast and has no OOMs
- Has a fuzzing dictionary, if applicable

Fix test/example.c when compiled with ASAN

Before this patch

cmake -DWITH_SANITIZERS=1
make
make test

used to fail with:

Running tests...
Test project /home/hansr/github/zlib/zlib-ng
    Start 1: example
1/2 Test #1: example ..........................***Failed    0.14 sec
    Start 2: example64
2/2 Test #2: example64 ........................***Failed    0.13 sec

==11605==ERROR: AddressSanitizer: memcpy-param-overlap: memory ranges [0x62e000000595,0x62e0000053b5) and [0x62e000000400, 0x62e000005220) overlap
    #0 0x7fab3bcc9662 in __asan_memcpy (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x8c662)
    #1 0x40f936 in memcpy /usr/include/x86_64-linux-gnu/bits/string3.h:53
    #2 0x40f936 in read_buf /home/spop/s/zlib-ng/deflate.c:1122
    #3 0x410458 in deflate_stored /home/spop/s/zlib-ng/deflate.c:1394
    #4 0x4133d7 in zng_deflate /home/spop/s/zlib-ng/deflate.c:945
    #5 0x402253 in test_large_deflate /home/spop/s/zlib-ng/test/example.c:275
    #6 0x4014e8 in main /home/spop/s/zlib-ng/test/example.c:536
    #7 0x7fab3b89382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #8 0x4018e8 in _start (/work/spop/zlib-ng/example+0x4018e8)

0x62e000000595 is located 405 bytes inside of 40000-byte region [0x62e000000400,0x62e00000a040)
allocated by thread T0 here:
    #0 0x7fab3bcd579a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
    #1 0x40147a in main /home/spop/s/zlib-ng/test/example.c:516

0x62e000000400 is located 0 bytes inside of 40000-byte region [0x62e000000400,0x62e00000a040)
allocated by thread T0 here:
    #0 0x7fab3bcd579a in __interceptor_calloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x9879a)
    #1 0x40147a in main /home/spop/s/zlib-ng/test/example.c:516

SUMMARY: AddressSanitizer: memcpy-param-overlap ??:0 __asan_memcpy
==11605==ABORTING

fix bug #183 following recommendations of Mika Lindqvist

 > the problem is in line c_stream.avail_in = (unsigned int)comprLen/2;
 > which feeds it too much data ... it should cap it to
 > c_stream.next_out - compr instead.

fix ASAN crash on test/minigzip

Before this patch, when configuring with address sanitizer:

./configure --with-sanitizers
make
make test

used to fail with the following error:

$ echo hello world | ./minigzip
ASAN:SIGSEGV
=================================================================
==17466==ERROR: AddressSanitizer: SEGV on unknown address 0x00000000fc80 (pc 0x7fcacddd46f8 bp 0x7ffd01ceb310 sp 0x7ffd01ceb290 T0)
    #0 0x7fcacddd46f7 in _IO_fwrite (/lib/x86_64-linux-gnu/libc.so.6+0x6e6f7)
    #1 0x402602 in zng_gzwrite /home/spop/s/zlib-ng/test/minigzip.c:180
    #2 0x403445 in gz_compress /home/spop/s/zlib-ng/test/minigzip.c:305
    #3 0x404724 in main /home/spop/s/zlib-ng/test/minigzip.c:509
    #4 0x7fcacdd8682f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    #5 0x4018d8 in _start (/work/spop/zlib-ng/minigzip+0x4018d8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV ??:0 _IO_fwrite
==17466==ABORTING

During compilation the following warnings point to a missing definition:

/home/spop/s/zlib-ng/test/minigzip.c:154:31: warning: implicit declaration of function 'fdopen' is invalid in C99 [-Wimplicit-function-declaration]
    gz->file = path == NULL ? fdopen(fd, gz->write ? "wb" : "rb") :
                              ^
/home/spop/s/zlib-ng/test/minigzip.c:154:29: warning: pointer/integer type mismatch in conditional expression ('int' and 'FILE *' (aka 'struct _IO_FILE *')) [-Wconditional-type-mismatch]
    gz->file = path == NULL ? fdopen(fd, gz->write ? "wb" : "rb") :
                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/home/spop/s/zlib-ng/test/minigzip.c:504:36: warning: implicit declaration of function 'fileno' is invalid in C99 [-Wimplicit-function-declaration]
            file = PREFIX(gzdopen)(fileno(stdin), "rb");
                                   ^
/home/spop/s/zlib-ng/test/minigzip.c:508:36: warning: implicit declaration of function 'fileno' is invalid in C99 [-Wimplicit-function-declaration]
            file = PREFIX(gzdopen)(fileno(stdout), outmode);
                                   ^
/home/spop/s/zlib-ng/test/minigzip.c:534:48: warning: implicit declaration of function 'fileno' is invalid in C99 [-Wimplicit-function-declaration]
                        file = PREFIX(gzdopen)(fileno(stdout), outmode);
                                               ^
5 warnings generated.

and looking at stdio.h that defines fdopen we see that it is only defined under
__USE_POSIX:

 #ifdef __USE_POSIX
/* Create a new stream that refers to an existing system file descriptor.  */
extern FILE *fdopen (int __fd, const char *__modes) __THROW __wur;
 #endif

This patch fixes the compiler warnings and the runtime ASAN error.

Revert "[ARM/AArch64] Add run-time detection of ACLE and NEON instructions under Linux. * Use getauxval() to check support for ACLE CRC32 instructions * Allow disabling CRC32 instruction check"

This reverts commit e7e80f4cd22346a2ea3cadad57ed574078aa5576.

[ARM/AArch64] Add run-time detection of ACLE and NEON instructions under Linux.
* Use getauxval() to check support for ACLE CRC32 instructions
* Allow disabling CRC32 instruction check

Update zlib.h

Tell compiler to adhere to C99 standards.
Exception being newer cmake versions that will decay to gnu99 in
certain situations. This decay currently hides a warning in minigzip,
but using C99 with C_STANDARD_REQUIRED on could potentially introduce
unknown problems on other platforms, so for now we will allow this decay.

fix bug #207: avoid undefined integer overflow

zlib-ng used to fail when compiled with UBSan with this error:
deflate_slow.c:112:21: runtime error: unsigned integer overflow: 45871 - 45872 cannot be represented in type 'unsigned int'

The bug occurs in code added to zlib-ng under `#ifndef NOT_TWEAK_COMPILER`.
The original code of zlib contains a loop with two induction variables:

  s->prev_length -= 2;
  do {
      if (++s->strstart <= max_insert) {
          functable.insert_string(s, s->strstart, 1);
      }
  } while (--s->prev_length != 0);

The function insert_string is not executed when
  !(++s->strstart <= max_insert)
i.e., when
  !(s->strstart + 1 <= max_insert)
  !(s->strstart < max_insert)
  max_insert <= s->strstart

The function insert_string is executed when
  ++s->strstart <= max_insert
i.e., when
  s->strstart + 1 <= max_insert
  s->strstart < max_insert

The function is executed at most `max_insert - s->strstart` times, following the
exit condition of the do-while `(--s->prev_length != 0)`.  If the loop exits
after evaluating the exit condition once, the function is executed once
independently of `max_insert - s->strstart`.  The number of times the function
executes is the minimum between the number of iterations in the do-while loop
and `max_insert - s->strstart`.

The number of iterations of the loop is `mov_fwd = s->prev_length - 2`, and we
know that this is at least one as otherwise `--s->prev_length` would overflow.

The number of times the function insert_string is called is
  `min(mov_fwd, max_insert - s->strstart)`

Fix clang scan-build "zlib-ng/memcopy.h:298:5: warning: Value stored to 'from' is never read"

fix #187: remove errors exposed by undefined behavior sanitizer

Move decrement in loop to avoid the following errors:
adler32.c:91:19: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
adler32.c:136:19: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'size_t' (aka 'unsigned long')
inflate.c:972:32: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int'

Fix the following bugs as recommended by Mika Lindqvist:
arch/x86/deflate_quick.c:233:22: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int'
arch/x86/fill_window_sse.c:52:28: runtime error: unsigned integer overflow: 1 - 8192 cannot be represented in type 'unsigned int'

Allow compiling with gzfileops from configure too

Add more --help output to configure

Fix ZLIB_COMPAT=OFF and WITH_GZFILEOP=ON compilation failure.
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.

Make functable thread-local.

fix bug #184: clear out buf to avoid msan use-of-uninitialized-value

Do not use bzero as suggested by Mika Lindqvist:
> You shouldn't use bzero() in new code as some compilers, like Visual C++,
> don't have it... New code should just use memset().

fix bug #192, oss-fuzz/9827 : MemorySanitizer:DEADLYSIGNAL

==4908==ERROR: MemorySanitizer: SEGV on unknown address 0x730fffffffff (pc 0x0000004b1b97 bp 0x7ffd4bf59a00 sp 0x7ffd4bf598a0 T4908)
==4908==The signal is caused by a READ memory access.
  #0 0x5a0599 in fizzle_matches zlib-ng/deflate_medium.c:168:12
  #1 0x59ea27 in deflate_medium zlib-ng/deflate_medium.c:296:21
  #2 0x5901c5 in zng_deflate zlib-ng/deflate.c:951:18
  #3 0x586955 in zng_compress2 zlib-ng/compress.c:59:15
  #4 0x5861eb in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:18:3
  #5 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  #6 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  #7 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  #8 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  #9 0x7fa3d7ff582f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
  #10 0x41ec68 in _start

fix bugs #186 and #191, oss-fuzz/9831: use-of-uninitialized-value

==1==WARNING: MemorySanitizer: use-of-uninitialized-value
  #0 0x59fa93 in deflate_medium zlib-ng/deflate_medium.c:259:21
  #1 0x590905 in zng_deflate zlib-ng/deflate.c:951:18
  #2 0x587095 in zng_compress2 zlib-ng/compress.c:59:15
  #3 0x5866e3 in check_compress_level zlib-ng/test/fuzz/compress_fuzzer.c:18:3
  #4 0x5862fd in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:38:3
  #5 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  #6 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  #7 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  #8 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  #9 0x7fea2fea482f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
  #10 0x41ec68 in _start
Uninitialized value was created by a heap allocation
  #0 0x45f2a0 in malloc /src/llvm/projects/compiler-rt/lib/msan/msan_interceptors.cc:910
  #1 0x587d42 in zng_deflateInit2_ zlib-ng/deflate.c:284:27
  #2 0x5874fa in zng_deflateInit_ zlib-ng/deflate.c:224:12
  #3 0x586c95 in zng_compress2 zlib-ng/compress.c:41:11
  #4 0x5866e3 in check_compress_level zlib-ng/test/fuzz/compress_fuzzer.c:18:3
  #5 0x5862fd in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:38:3
  #6 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  #7 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  #8 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  #9 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  #10 0x7fea2fea482f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291

fix #197, oss-fuzz/10036: only write 4 bytes per iteration in deflate_quick

by aggregating the two consecutive values to be written by static_emit_ptr to
s->pending_buf and writing the two values at once in a 4 byte store, we avoid
running out of the allocated buffer. We used to call quick_send_bits twice and
bumped the counter s->pending in the first call, which made the second call
write to memory beyond the safe 4 bytes that were guaranteed by the following
condition in the enclosing loop in deflate_quick:

  if (s->pending + 4 >= s->pending_buf_size) {
    flush_pending(s->strm);

The bug was exposed by the memory sanitizer like so:

MemorySanitizer:DEADLYSIGNAL
--
  | ==1==ERROR: MemorySanitizer: SEGV on unknown address 0x730000020000 (pc 0x0000005b6ce4 bp 0x7fff59adb5e0 sp 0x7fff59adb570 T1)
  | ==1==The signal is caused by a WRITE memory access.
  | #0 0x5b6ce3 in quick_send_bits zlib-ng/arch/x86/deflate_quick.c:134:48
  | #1 0x5b5752 in deflate_quick zlib-ng/arch/x86/deflate_quick.c:243:21
  | #2 0x590a15 in zng_deflate zlib-ng/deflate.c:952:18
  | #3 0x587165 in zng_compress2 zlib-ng/compress.c:59:15
  | #4 0x5866d3 in check_compress_level zlib-ng/test/fuzz/compress_fuzzer.c:22:3
  | #5 0x5862d8 in LLVMFuzzerTestOneInput zlib-ng/test/fuzz/compress_fuzzer.c:74:3
  | #6 0x4e9b48 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:575:15
  | #7 0x4a2f66 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) /src/libfuzzer/FuzzerDriver.cpp:280:6
  | #8 0x4b3adb in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:715:9
  | #9 0x4a2091 in main /src/libfuzzer/FuzzerMain.cpp:20:10
  | #10 0x7fb8919b082f in __libc_start_main /build/glibc-Cl5G7W/glibc-2.23/csu/libc-start.c:291
  | #11 0x41ec68 in _start
  | MemorySanitizer can not provide additional info.
  | SUMMARY: MemorySanitizer: SEGV (/mnt/scratch0/clusterfuzz/slave-bot/builds/clusterfuzz-builds_zlib-ng_7ead0a3e4980f024583384fd355b6e3ddd4b2ca2/revisions/compress_fuzzer+0x5b6ce3)

replaced include_directories() with target_include_directories()

using target_include_directories() with the zlib libraries prevents people from having to manually include those directories when linking to those libraries

Reset CMAKE_REQUIRED_FLAGS

Reset CMAKE_REQUIRED_FLAGS after each check to avoid the following
checks being influenced by the previous results.

Change-Id: I2e34f6127ef1c617f4eea363a2cb80bc49b3bcab
Signed-off-by: Richael Zhuang <richael.zhuang@arm.com>

Add check for -mfpu=neon (#171)

For 64bit armv8-a there's no need to use "-mfpu=neon" to enable NEON.
But for 32bit system "-mfpu=neon" is required.

This patch adds the detection for -mfpu=neon flag.

Signed-off-by: Richael Zhuang richael.zhuang@arm.com

travis: add linux-ppc64le

Add the support for some missing cross-compile tool chains in zlib-ng

Change-Id: I7b5c9acd0b3e43079e59c3da9eac161475408f83
Signed-off-by: Richael Zhuang <richael.zhuang@arm.com>

Separate feature checks for x86 and x86_64
* Don't check for SSE2 on anything else than i685
* Don't check for PCLMULQDQ on anything else than i686 or x86_64
* Check for SSE4.2 CRC intrinsics

CMake: don't assume i[3456]86 if others don't match

Match these architectures explicitly and fall back to generic.

[ARM] Disable ACLE support if uname returns "eabi".
* Warn if current processor doesn't support ACLE or NEON.

Add ARM cross build and validation

Update configure and test scripts to cross compile
and validate arm build-outs on x86 by using qemu

Change-Id: I183d003ebafcf686de26fd1705704ded4b344580
Signed-off-by: Jun He <jun.he@arm.com>

Move private defines from zconf.h and zconf-ng.h to zbuild.h
* move definition of z_size_t to zbuild.h