[Zlib-devel] zlib 1.2.4 released

[Nelson H. F. Beebe]

Mark, I now have 25 successful builds and validation suite passes of
zlib-1.2.4 in my test lab.  As you suggested, I have not installed any
them until 1.2.4 is official.

There were no significant build failures related to zlib.

There was, however, one test failure on DEC OSF/1 Alpha with the
native cc compiler:

    % ./example
    zlib version 1.2.4 = 0x1240, compile flags = 0x30000a9
    uncompress(): hello, hello!  Segmentation fault (core dumped)

    %  dbx example
    dbx version 3.11.10 Type 'help' for help.

    (dbx) run
    zlib version 1.2.4 = 0x1240, compile flags = 0x30000a9
    uncompress(): hello, hello!
    signal Segmentation fault at >*[strlen, 0x3ff801a2ce0]  ldq_u   r1, 0(r16)
    (dbx) where
    >  0 strlen(0x6e79642e6c65722e, 0x3ff80080700, 0x3ff80080700, 0x4380, 0x700) [0x3ff801a2ce0]
       1 _doprnt(0x102, 0x3ffc008acc8, 0x102, 0x3ffc008acd0, 0x102) [0x3ff800ddcc8]
       2 sprintf(0x14001e000, 0x1400024b8, 0x400024c0, 0x4001e004, 0x1) [0x3ff800da08c]
       3 gzprintf(0x1400024a8, 0x140004100, 0x1400024b8, 0x4001e004400024c0, 0x4000264000000001) [0x12000d388]
       4 test_gzio(0x140002598, 0x9c40, 0xe, 0x13, 0x140006000) [0x120003058]
       5 main(0x14000d320, 0x9c40, 0x11fffe6a8, 0x3ff00000001, 0x140002590) [0x120004990]

    (dbx) p *(char*)0x6e79642e6c65722e
    can't read from process (address 0x6e79642e6c65722e)

    (dbx) p *(char *)0x1400024a8
    'w'

The DEC compilers, like those of Sun, have always been trustworthy, so
the failure here is certainly unexpected.

Tests with four different versions of gcc on the Alpha box all passed.

I then rebuilt the zlib library with cc -g, and with dbx, found, I
think, the problem:

(1) example.c:108 has

	if (gzprintf(file, ", %s!", "hello") != 8) {...}

(2) gzwrite.c:352 has

	int ZEXPORTVA gzprintf (file, format, a1, a2, a3, a4, a5, a6, a7, a8, a9, a10,
			       a11, a12, a13, a14, a15, a16, a17, a18, a19, a20)
	    gzFile file;
	    const char *format;
	    int a1, a2, a3, a4, a5, a6, a7, a8, a9, a10,
		a11, a12, a13, a14, a15, a16, a17, a18, a19, a20;

(3) gzwrite.c:398 has

	len = sprintf(state->in, format, a1, a2, a3, a4, a5, a6, a7, a8,
		    a9, a10, a11, a12, a13, a14, a15, a16, a17, a18, a19, a20);

The problem is that int on this system is a 4-byte value, whereas all
pointers are 8-byte values.  Thus, the trick of supply fake integer
arguments instead of using Standard C's <stdarg.h> or K&R C's
<varargs.h> does not work on this platform, since four bytes of each
address are lost.

-------------------------------------------------------------------------------
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: beebe at math.utah.edu  -
- 155 S 1400 E RM 233                       beebe at acm.org  beebe at computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
-------------------------------------------------------------------------------