We need to match the order of inclusions at the top of the file
otherwise we might end up trying to use arc4random_buf() when
available (because HAVE_ARC4RANODM_BUF is set) even though
we hit HAVE_GETRANDOM first above and only included
<sys/random.h> because of it.
Besides, if getrandom() is available, we should really prefer
it anyway.
Fixes an implicit function declaration:
```
minizip-ng-3.0.6/mz_os_posix.c:124:5: error: implicit declaration of function 'arc4random_buf' [-Werror=implicit-function-declaration]
```
Signed-off-by: Sam James <sam@gentoo.org>
When running ctest it also builds and runs example and example64 from zlib.
The GCC CI builds were failing because example and example64 could not find
the header file zlib.h.
This reverts commit fe36527157ff96226f5309a99c806475ee0b75d2, which
changed the POSIX mz_os_get_file_date to always remove the last
character from the filename before calling stat() (regardless of whether
the filename ended in a slash).
NUL termination was correct before that change, because "len+1" always
includes the NUL byte at the end of the input string (unless you somehow
have a string that consumes the entire address space and len+1
overflows, but then where would the rest of the program data reside?).
Fix the following build failure without a working C++ compiler raised
since version 2.0.0 and
d383a5f2fc:
CMake Error at /nvmedata/autobuild/instance-20/output-1/host/share/cmake-3.18/Modules/CMakeTestCXXCompiler.cmake:59 (message):
The C++ compiler
"/usr/bin/c++"
is not able to compile a simple test program.
Fixes:
- http://autobuild.buildroot.org/results/4452bc35b41414a5e8a0e9831b0854228df5fba4
Signed-off-by: Fabrice Fontaine <fontaine.fabrice@gmail.com>
When minizip-ng is used as a git submodule in a project where MZ_COMPAT is enabled, VS Code's Git integration will highlight zip.h and unzip.h as untracked files, which is annoying.
If a path of length 0x10001 is passed into this function, the value of
len after truncating to int16_t will be greater than 0, so the function
will proceed to allocate a 2 byte buffer and copy 65538 bytes into it.
Avoid issues with truncation by keeping len in size_t.
The path may be overrun by two bytes. One because mz_path_append_slash
may append to path without updating path_len, and another one because
strncat always appends a NUL byte after writing N bytes.
Rescan the path length and subtract one from the strncat length parameter
to make sure we stay within max_path.
