This looks like a bug in the zip source package configure file.

I think the "OF" macro is irrelevant in this particular case - it's a macro that in this case does nothing, since tailor.h is included earlier.

According to a man page dated 2017-03-13 for memset, it appears that under POSIX.1-2001, POSIX.1-2008, C89, C99, SVr4, 4.3BSD, the declaration of memset should be:

void *memset(void *s, int c, size_t n);

So the zip definition ifdef ZMEM does appear to be in contradiction to the POSIX standards. It appears to be enabled by the compile line

cc ... -DZMEM ...

(though strictly speaking this is for crc32.c; my guess is that we see the bug with zip.c instead of crc32.c due to parallel compiling).

It appears that these lines in unix/configure (in zip-3.0) fail to detect a system-level memset and so they enable the -DZMEM compile flag:

   521  echo Check for memset
   522  echo "int main(){ char k; memset(&k,0,0); return 0; }" > conftest.c
   523  $CC -o conftest conftest.c >/dev/null 2>/dev/null
   524  [ $? -ne 0 ] && CFLAGS="${CFLAGS} -DZMEM"
   525

It looks like this configure section is buggy: the include line

#include <string.h>

is absent from the configure script.

Fixing this upstream at http://infozip.sourceforge.net/Zip.html#Release does not look realistic since the latest release is 7 July 2008, although in principle we should try.

The equivalent bug exists in unzip-6.0 , which does not appear to be maintained.

With our current definition of gbuild in build-rules.mk, there are no options for modifying the configure file after unpacking the tarball and before configuring (nor for modifying the Makefile before running make), and it appears that CFLAGS="-DBIG_MEM -DMMAP" is ignored (the configure script looks like a handwritten script, not the usual autotools script made with autoconf), so adding another flag such as -UZMEM would not work as a workaround.

Options for zip + unzip that I see are:

(1a) copy/paste the gbuild instructions into the zip + unzip rules in basic.mk and insert an sed command to replace the existing creation of conftest.c for ZMEM in configure by

printf "#include <string.h>\nint main(){ char k; memset(&k,0,0); return 0; }\n" > conftest.c

or

(1b,c) modify gbuild to be a bit more flexible so that we can do essentially the same as (1), but without the big copy/paste of the rest of the unpack/configure/compile/install cycle, either (1b) with an sed command or (1c) with a patch file;

or

(2) provide our own fork of zip-3.0 and unzip-6.0 on a git repository with this change (and later mirrored on akhlaghi.org and zenodo, but best to also have an upstream git repository).


Why does gcc compile zip and unzip without a problem?
My guess: gcc works because it considers the conftest.c lack of an include statement to be only a warning, not an error, and returns 0 in the configure test.

So in terms of POSIX standards, the "problem" in this case, if I've understood it correctly, is that gcc is "too reasonable", and Darwin/xnu + Xcode is too strict, but is formally correct.


What option would be best - (1a), (1b), (1c) or (2) or (other)?