reproduce-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #60256] Crash when building Zip/Unzip after macOS upgrade


From: Boud Roukema
Subject: [bug #60256] Crash when building Zip/Unzip after macOS upgrade
Date: Fri, 16 Jul 2021 17:36:53 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Firefox/78.0

Follow-up Comment #1, bug #60256 (project reproduce):

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)?


    _______________________________________________________

Reply to this item at:

  <https://savannah.nongnu.org/bugs/?60256>

_______________________________________________
  Message sent via Savannah
  https://savannah.nongnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]