[prev in list] [next in list] [prev in thread] [next in thread] 

List:       zlib-devel
Subject:    [Zlib-devel] Zlib 1.2.6.1 (git) on OpenVMS
From:       zinser () zinser ! no-ip ! info (zinser at zinser ! no-ip ! info)
Date:       2012-02-26 20:37:07
Message-ID: 12022621370742_1F995 () zinser ! no-ip ! info
[Download RAW message or body]

Hello,

some more news from Zlib adventures in OpenVMS land ;-)

I've tested the latest git version (pulled Feb, 26th) on 

OpenVMS VAX 7.3
OpenVMS Alpha 8.3
OpenVMS IA64 8.4

The only issue in the actual Zlib code I've encountered was on the VAX, where 
the compiler is very picky:
 
CC /decc/prefix=all GZWRITE.C
            len = vsprintf(state->in, format, va);
        ...................^
%CC-W-PTRMISMATCH1, In this statement, the referenced type of the pointer value
 "state->in" is "unsigned char", which is not compatible with "char" because
 they differ by signed/unsigned attribute.
                At line number 346 in DKA300:[PUBLIC.UTIL.LIBS.ZLIB_GIT]GZWRITE.C;1.

Looking at the available documentation (not only on OpenVMS) the argument type 
really should be char*. Most compilers do the upconversion silently. On the 
other hand the following patch looks harmless 

--- gzwrite.c.orig      2012-02-20 09:24:30.000000000 +0100
+++ gzwrite.c   2012-02-26 19:57:28.394041653 +0100
@@ -343,7 +343,7 @@
     for (len = 0; len < size; len++)
         if (state->in[len] == 0) break;
 #  else
-    len = vsprintf(state->in, format, va);
+    len = vsprintf((char *)(state->in), format, va);
     va_end(va);
 #  endif
 #else

If the patch is unacceptable, I can silence this class of errors in the build
procedure. In general I try to avoid this, since it obviously can mask real 
problems.

Else I found a couple of issues in my build procedure while running it after 
many years for the first time on a VAX again. Patch and full make_vms.com 
are on http://zinser.no-ip.info/trans/zlib_1261_diff_vms.zip

The build script has still room for improvement, but at least it is working 
correctly on all supported OpenVMS HW plattforms now again.

Streamlining the script code will happen for the next release, I promise :-)

Greetings, Martin



[prev in list] [next in list] [prev in thread] [next in thread]