zlib1.2.3

[Xueming Shen]

Martin Buchholz wrote:
>
> I imagine that the only issue with having unsigned long be 64-bit is that
> crc32.c will compute a 32-bit integer, it will get widened to 64-bit,
> and then narrowed back to 32-bit, which is allowed in C and harmless
> (although there might be a warning),
> but not in Java, where you have to explicitly cast to throw away the
> top 32 bits.
>
> Martin
>   
Given "uLong" is used widely in zlib.h,  I would like to keep it asis 
(to be 32-bit as we have been doing
for years). So the question is can you live with the following simle 
"local change" in crc32.c. crc32.h therefor
will remained untouched, the same as the original zip (which means the 
crc32 is calculated on 64-bit
actually, I'm not sure the impact of "register u4 c" will have, but 
believe it will use up a full 64-bit register
anyway).

--- /home/sherman/TL/zlib-1.2.3_ORG/crc32.c	Sun Jun 12 16:56:07 2005
+++ ../../../src/share/native/java/util/zip/zlib-1.2.3/zcrc32.c	Mon Aug 24 15:10:22 2009
@@ -216,8 +216,8 @@
 #define DO8 DO1; DO1; DO1; DO1; DO1; DO1; DO1; DO1
 
 /* ========================================================================= */
-unsigned long ZEXPORT crc32(crc, buf, len)
-    unsigned long crc;
+uLong ZEXPORT crc32(crc, buf, len)
+    uLong crc;
     const unsigned char FAR *buf;
     unsigned len;
 {
@@ -234,9 +234,9 @@
 
         endian = 1;
         if (*((unsigned char *)(&endian)))
-            return crc32_little(crc, buf, len);
+            return (uLong)crc32_little(crc, buf, len);
         else
-            return crc32_big(crc, buf, len);
+            return (uLong)crc32_big(crc, buf, len);
     }
 #endif /* BYFOUR */

     crc = crc ^ 0xffffffffUL;


It should be a safe change, and "much less" than the original one:-) If 
you're OK with this, I can go kick start
the build and test.

btw, I really don't like the big/littleendian detecting code...but 
should not be a big deal if mostly we do bulk
calculation.

sherman