On 03/09/18 23:58, Antonio Scuri wrote:
Hi,
I downloaded the latest zlib code 1.2.11, from that I extracted the
minzip utilities and copied to CD. The application code in mini*.c I
ignored because we wrote our own. So the CD code now has the latest minizip
utilities code.
I also committed your patch, but with less comments.
Best,
Scuri
Thank you for that. I've just tried the modified code on my Gentoo setup,
and it has not failed. Nice (but not an exhaustive test, and I haven't
tried the code on GNU/Linux Mint (roughly, Ubuntu) yet).
A few notes on zlib 1.2.11-r1:
1. The "-r1" states that an extra patch has been applied to the 1.2.11 sources.
Gentoo-specific code is GPL v2, but I'm not sure whether this applies to
this patch. 1.2.11-r1 is marked as the "current stable version" for all
machine architectures, a definition that typically comes from an upstream
maintainer (Debian/Ubuntu?).
I will contact the maintainer of zlib, Mark Adler:
mailto:Mark Adler, <mad...@alumni.caltech.edu>
to see if there is anything post-1.2.11, to clarify the exact state of
zlib, including post-1.2.11 patches, and also any licensing issues.
2. The key reason for attacking the OF macro was not merely that it was
troublesome on one system, but especially because I saw some incorrect code
(although I didn't keep proper notes at the time): The definition:
#ifndef OF
# define OF(args) _Z_OF(args)
#endif
is invalid C and/or C preprocessor code, as the various ISO C standards
mandate that all identifiers starting with an underscore are reserved for
use by non-application parties (e.g. preprocessor, compiler, assembler,
linker, external support libraries (including, but not limited to, libc),
the OS and other parties.
The macro "_Z_OF" violates the C standards, and so needs to be removed,
and, if required, replaced with a conforming identifier.
The standard states that the results are undefined if the application
does not conform to the rules. "Undefined" needs to be clearly
understood here: It can be any of:
* Works perfectly, both now, and on all future hardware/OS/library
variations;
* Might work today, but mysteriously start crashing when some future
external component is changed;
* Might show erratic behaviour, e.g. perhaps mostly working, but
just occasionally, under the right circumstances, enter an infinite
loop;
* Might see erratic operation like failures that only arise when
certain features (optimisation levels? OpenMP processing?) are
enabled;
* Interfere with the correct operation of another part of the
application;
* Perhaps brick the machine entirely; and/or
* A huge spectrum of other possibilities.
(I've found, over the years, that some programmers want to assign some
meaning to "undefined" in particular circumstances; I've always tried
to dissuade them of this notion, simply stating that "you've strayed
outside the agreed contract, and so *absolutely all bets are off*".)
3. I'm slightly surprised by your "wrote your own" comment regarding
minizip.c and miniunzip.c (actually, "miniunz.c"), as there is a version
of these files both in zlib-1.1 and in zlib-1.2.11.
I thought that the older minizip code in CD looked like a trimmed-down
and reworked version of the 1.1 code.
When I looked at the 1.2.11 code, I found it quite significantly
refactored to handle 64-bit file offsets and so break the 4 GiB boundary
for both the whole archive, and for individuals within it.
Thanks again,
s-b
its-too-early-in-the-morning-for-me-to-be-writing-long-emails-such-as-this-one
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Iup-users mailing list
Iup-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/iup-users
