On Mon, Aug 24, 2009 at 15:24, Xueming Shen<xueming.s...@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
