zlib1.2.3

[Xueming Shen]

Thanks Martin1

We are very close:-)

Here is the latest webrev, compared to the last one, the only changes are

(1)zcrc.c, the "compromised" change you approved.
(2)undo any change in crc.h
(3)a final tweak in zlib.h, this one is used by nobody and never 
exported. Just to make compile happy

  21 -ZEXTERN const unsigned long FAR * ZEXPORT get_crc_table    OF((void));
  22 +ZEXTERN const uLongf * ZEXPORT get_crc_table    OF((void));

http://cr.openjdk.java.net/~sherman/zlib123/webrev

Tests (all related jar/zip/pack/unpack tests, LargZip, jar c/x/t of 
large(>6g) zip, pack200/unpack200 of rt.jar,
ZlibTest on all standard jdk jar lirbraries) have been done on Solaris 
sparc/i586 32-bit &64-bit, Linux 64-bit,
Windows XpVista 32-bit and 2003 Server 64-bit. One last test is still 
running on a sparc 32-bit (jar up single > 6G file).

Let me know if you guys are OK with  the latest one.

Sherman


Martin Buchholz wrote:
> On Mon, Aug 24, 2009 at 15:24, Xueming Shen<Xueming.Shen at sun.com> wrote:
>   
>> 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;
>>     
>
> I approve of this compromise, and also
> approve of making the corresponding change to
> crc32_little and crc32_big, if you wish to do that.
>
>   
>> 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.
>>     
>
> endian-detection should happen at configure-time, not run time.
> But zlib does not have a history of an extensive "configure layer".
> And I don't think it is possible to determine endian-ness using
> only the C preprocessor.  Hence the current situation.
>
> Martin
>