[Zlib-devel] zlib 1.2.0.1 available for testing
Cosmin Truta
cosmin at cs.toronto.edu
Wed Mar 19 21:53:01 EST 2003
On Mon, 17 Mar 2003, Mark Adler wrote:
> You can get the special St. Patty's Day edition of zlib, version
> 1.2.0.1 here:
>
> http://www.alumni.caltech.edu/~madler/zlib-1.2.0.1.tar.gz
And you can get my update to this version from here:
http://www.cs.toronto.edu/~cosmin/pngtech/z_rle/zlib-1.2.0.1-cos.zip
http://www.cs.toronto.edu/~cosmin/pngtech/z_rle/zlib-1.2.0.1-cos.diff
Some of the changes were in the last zlib-1.2.0-rle submission. So,
Mark, if you considered those, but did not incorporate them yet into
this version, that's fine. But if you will reject any of these, please
let me know, so I won't bug you with them next time :)
1. ZLIB_INTERNAL is #defined in every zlib source file, except
example.c and minigzip.c.
2. _ZLIB_H and the other header guards do not comply to the requirements
of the language. All symbols starting with _Capital or __anything
are reserved for compilers and library implementations. So it should
be either ZLIB_H or _zlib_h. I thought you would prefer ZLIB_H,
ZUTIL_H, etc., and I incorporated the changes.
3. ZEXTERN const char * ZEXPORT zlibVersion OF((void));
was changed to
ZEXTERN const char ZEXPORT * zlibVersion OF((void));
etc.
4. The sequence
/* Old Borland C incorrectly complains about missing returns: */
#if defined(__BORLANDC__) && (__BORLANDC__ < 0x460)
# define NEED_DUMMY_RETURN
#endif
#if defined(__TURBOC__) && !defined(__BORLANDC__)
# define NEED_DUMMY_RETURN
#endif
looks like a leftover to me, and it was removed. There is no
NEED_DUMMY_RETURN in the source files, and I supposed that particular
workaround was eliminated some time ago.
5. The guard
#if !defined(STDC99) && !(defined(__TURBOC__) && __TURBOC__ >= 0x550) && !defined(VSNPRINTF_DEFINED)
was changed to
#if !defined(STDC99) && !(defined(__TURBOC__) && __TURBOC__ >= 0x550) && !defined(HAVE_VSNPRINTF)
because I concluded from the previous discussions that ./configure
sets HAVE_VSNPRINTF, not VSNPRINTF_DEFINED. There is no point in
supporting both symbols.
6. win32/zlib.def was updated.
I took the missing lines from Gilles' minizip.
There also are some changes in the win32 makefiles. I added
-DZLIB_DLL to CFLAGS, and I also added a comment about using -MD.
I wish to point out that the zlib.def included in contrib/vstudio
contains export numbers of non-zlib symbols, that are dangerously
close to those of zlib. I would prefer not to have minizip exports in
ZLIB.DLL, or at least to have it with a different name, such as
ZLIBZIP.DLL
-- but if you really wish to do it, at least please use export
numbers above 100.
I think that minizip is a very useful addition to zlib, but as long
as it isn't an official part of zlib, but a 3rd-party addition, it
shouldn't be exported by ZLIB.DLL
7. [observation only]
Gilles, I noticed that contrib/vstudio/vc15_16/zlib16.mak contains
absolute paths like "c:\zlib\zlib.h". Are you aware of them? Can they
be converted to relative paths?
8. I suggest removing:
old/nt/makefile.nt
old/nt/makefile.gcc
old/nt/zlib.dnt
because they already exist in the new win32 directory.
9. There are a couple of updates to deflate.c
This allows the detection of incorrect initialization, when level < 0
#ifdef FASTEST
- if (level != 0) level = 1;
+ if (level > 0) level = 1;
#else
if (level == Z_DEFAULT_COMPRESSION) level = 6;
#endif
Please note that this fix is applied two times, once inside
deflateInit2_(), and once inside deflateParams().
Even if 256-byte windows are currently invalidated due to the
existing bug, an user calling deflateInit() with windowBits=8
should not get an initialization error, because it indicates a
valid window size. My idea makes both old software (that used to
use windowBits=8) and future software (that may link to a future
version of zlib in which this bug is fixed) work with the current
zlib.
@@ -254,8 +255,11 @@
noheader = 1;
windowBits = -windowBits;
}
+ if (windowBits == 8) { /* set windowBits to a safe value */
+ windowBits = 9; /* until the 256-byte window bug is fixed */
+ }
if (memLevel < 1 || memLevel > MAX_MEM_LEVEL || method !=
Z_DEFLATED ||
- windowBits < 9 || windowBits > 15 || level < 0 || level > 9 ||
+ windowBits < 8 || windowBits > 15 || level < 0 || level > 9 ||
strategy < 0 || strategy > Z_RLE) {
return Z_STREAM_ERROR;
}
Besides, in the actual implementation, a 512-byte window does not
allow distances bigger than 252, and this means the CINFO flag can
safely indicate a 256-byte window (which is a memory optimization
for the sake of the decoder). There is a patch that applies
to the old zlib-1.1.3, still available from here:
http://www.cs.toronto.edu/~cosmin/pngtech/zlib-256win-bug.html
I did not adapt this patch to zlib-1.2.x, but I can do it if you
want.
The patch below makes all compilers (including mine) happy.
The old workaround wasn't too helpful, because it tried to shut up
a useless assignment warning (that occured previously within a macro)
with another useless assignment.
- if (hash_head) hash_head = 0; /* to make compiler happy */
- return Z_OK;
+ return (hash_head ? Z_OK : Z_OK); /* make compilers happy */
The patch below sets the CINFO level flags correctly when
Z_HUFFMAN_ONLY or Z_RLE is used. It should be 0 ("super-fast"),
instead of corresponding to the actual compression level, which
is ignored anyway.
@@ -520,9 +523,14 @@
if (s->status == INIT_STATE) {
uInt header = (Z_DEFLATED + ((s->w_bits-8)<<4)) << 8;
- uInt level_flags = (s->level-1) >> 1;
+ uInt level_flags;
- if (level_flags > 3) level_flags = 3;
+ if (s->strategy <= Z_FILTERED) {
+ level_flags = (s->level-1) >> 1;
+ if (level_flags > 3) level_flags = 3;
+ } else {
+ level_flags = 0;
+ }
header |= (level_flags << 6);
if (s->strstart != 0) header |= PRESET_DICT;
header += 31 - (header % 31);
Checking for "sizeof(more) <= 2" happens at compile time, so it is
possible to avoid some dead branches in 32-bit code. The fix I am
submitting now eliminates one more branch, comparing to what I
submitted in zlib-1.2.0-rle-beta1.
The whole thing is trying to avoid "64K - 0 - 0 == 0" and
"64K - 1 - 0 == -1" that happens in 16 bits, but is pointless in
any bigger machine.
@@ -1028,19 +1036,23 @@
more = (unsigned)(s->window_size -(ulg)s->lookahead -(ulg)s->strstart);
/* Deal with !@#$% 64K limit: */
- if (more == 0 && s->strstart == 0 && s->lookahead == 0) {
- more = wsize;
-
- } else if (more == (unsigned)(-1)) {
- /* Very unlikely, but possible on 16 bit machine if strstart == 0
- * and lookahead == 1 (input done one byte at time)
- */
- more--;
+ if (sizeof(more) <= 2) {
+ if (more == 0 && s->strstart == 0 && s->lookahead == 0) {
+ more = wsize;
+
+ } else if (more == (unsigned)(-1)) {
+ /* Very unlikely, but possible on a 16-bit machine
+ * if strstart == 0 and lookahead == 1
+ * (input done one byte at time)
+ */
+ more--;
+ }
+ }
/* If the window is almost full and there is insufficient lookahead,
* move the upper half to the lower one to make room in the upper half.
*/
- } else if (s->strstart >= wsize+MAX_DIST(s)) {
+ if (s->strstart >= wsize+MAX_DIST(s)) {
The value of TOO_FAR=4096 is fine when compressing generic text or
binary files, but when compressing multimedia data, such as images
(PNG), the results are better when TOO_FAR does not exist.
Setting TOO_FAR=32767 or bigger has the same effect as eliminating
it. See more about this here:
http://www.cs.toronto.edu/~cosmin/pngtech/too_far.html
@@ -1347,9 +1359,12 @@
}
/* longest_match() or longest_match_fast() sets match_start */
- if (s->match_length <= 5 &&
(s->strategy == Z_FILTERED ||
- (s->match_length == MIN_MATCH &&
- s->strstart - s->match_start > TOO_FAR))) {
+ if (s->match_length <= 5 && (s->strategy == Z_FILTERED
+#if TOO_FAR > 0 && TOO_FAR < 32767
+ || (s->match_length == MIN_MATCH &&
+ s->strstart - s->match_start > TOO_FAR)
+#endif
+ )) {
/* If prev_match is also MIN_MATCH, match_start is garbage
* but we will ignore the current match anyway.
**
You are not sleeping yet? Good! ;)
Cosmin
More information about the Zlib-devel
mailing list