On Tue, Aug 25, 2009 at 12:10, Xueming Shen wrote:
> 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 us
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
2
On Mon, Aug 24, 2009 at 15:24, Xueming Shen 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 harmles
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
On Mon, Aug 24, 2009 at 14:21, Xueming Shen wrote:
> Martin Buchholz wrote:
> Re:
> "I don't see why the rest of the jdk has to be changed,
> or why a completely unmodified zlib cannot be used"
>
> Current CRC32 and pack/zip.c expect a 32bit unsigned uint from zlib crc32().
> If we keep the new cr
but I'm pretty much sure
we are safe on this one).
The current implementation interfaces with the zlib via in/out byte
buffer. I don't there is anything 64-bit file
offset issue to "resolve" inside zlib1.2.3.
I was reminded that the b72 (tonight deadline) is the last build o
On Mon, Aug 24, 2009 at 11:16, Xueming Shen wrote:
> Martin Buchholz wrote:
>>
>> mit if you insist!
>>
>> Oh, I see your point. Are you saying this "local change" is not
>> necessary since it never gets
>> preprocessed?
>>
>> No, more than that - the code is defining a derived type
On Mon, Aug 24, 2009 at 11:06, Xueming Shen wrote:
> Florian Weimer wrote:
>>
>> * Martin Buchholz:
>>
>>
>>>
>>> 45 +#ifdef _LP64
>>> 46 +typedef unsigned int uLong; /* 32 bits or more */
>>> 47 +#else
>>> 48 typedef unsigned long uLong; /* 32 bits or more */
>>> 49 +#endif
>>>
>>
>> This
uot;similar" things into one project and end up missing the
> primary
> goal:-) Given the zlib is so "important", I would like to safe-land the
> zlib1.2.3 first,
> without touching too many other stuff.
Agreed.
> Personally I agree, there is good reason to use the
Martin Buchholz wrote:
mit if you insist!
Oh, I see your point. Are you saying this "local change" is not
necessary since it never gets
preprocessed?
No, more than that - the code is defining a derived type u4 from
primitive types - it should not be using othe
Florian Weimer wrote:
* Martin Buchholz:
45 +#ifdef _LP64
46 +typedef unsigned int uLong; /* 32 bits or more */
47 +#else
48 typedef unsigned long uLong; /* 32 bits or more */
49 +#endif
This is guaranteed to break interoperability with the system zlib. If
you want to m
y
goal:-) Given the zlib is so "important", I would like to safe-land the
zlib1.2.3 first,
without touching too many other stuff.
Personally I agree, there is good reason to use the zlib from native
platform/resource,
"depending on your perspective", as Joe said. However there
It is reasonable for jni code to be built against the system zlib.
Such jni code should not accidentally invoke the jdk bundled zlib.
zlib includes support for symbol renaming (Z_PREFIX),
but better is to build the jdk so that jni does not have direct access
to the zlib functions under any name (bu
* Martin Buchholz:
> 45 +#ifdef _LP64
> 46 +typedef unsigned int uLong; /* 32 bits or more */
> 47 +#else
> 48 typedef unsigned long uLong; /* 32 bits or more */
> 49 +#endif
This is guaranteed to break interoperability with the system zlib. If
you want to make such adjustments, yo
On Sun, Aug 23, 2009 at 21:56, Xueming Shen wrote:
> Martin Buchholz wrote:
>
>> On Sat, Aug 22, 2009 at 20:37, Xueming Shen wrote:
>>
>>
>>> -
31 @@ -39,7 +63,7 @@
32 typedef unsigned int u4;
33 #else
34 # if (ULONG_MAX == 0xUL)
Martin Buchholz wrote:
On Sat, Aug 22, 2009 at 20:37, Xueming Shen wrote:
-
31 @@ -39,7 +63,7 @@
32 typedef unsigned int u4;
33 #else
34 # if (ULONG_MAX == 0xUL)
35 - typedef unsigned long u4;
36 + typedef uLong u4;
37 # else
On Fri, Aug 21, 2009 at 08:46, Xueming Shen wrote:
> Martin Buchholz wrote:
>>
>> Do we really need to rename files? That's quite confusing.
>
> The names conflict with our CRC32.c and Adler.c on Windows platform.
YUK! I finally understand this problem.
Good makefile hygiene would be to build z
On Sat, Aug 22, 2009 at 20:37, Xueming Shen wrote:
>> -
>> 31 @@ -39,7 +63,7 @@
>> 32 typedef unsigned int u4;
>> 33 # else
>> 34 # if (ULONG_MAX == 0xUL)
>> 35 - typedef unsigned long u4;
>> 36 + typedef uLong u4;
>> 37 # else
>>
On Sat, Aug 22, 2009 at 20:37, Xueming Shen wrote:
>> -
>>
>> 35 +/* for _LP64 */
>> 36 +#include
>> 37 +
>> 38 /*
>> 39 * If you *really* need a unique prefix for all types and
>> library functions,
>> 40 * compile with -DZ_PREFIX. The "standard" zlib should be
>> compiled
On Sun, Aug 23, 2009 at 11:04, Xueming Shen wrote:
> Martin,
>
> Forgot to mentioned in last email, the original zlib.h actually has crc32
> declared using uLong, so
> we have a compiling error on 64-bit after we define the uLong to 32-bit
> unsigned, since the unsigned
> long is 64-bit in crc32.c.
Martin,
Forgot to mentioned in last email, the original zlib.h actually has
crc32 declared using uLong, so
we have a compiling error on 64-bit after we define the uLong to 32-bit
unsigned, since the unsigned
long is 64-bit in crc32.c.
sherman
Xueming Shen wrote:
I'm suspicious that the ch
Martin Buchholz wrote:
On Fri, Aug 21, 2009 at 11:09, Xueming Shen wrote:
Martin, webrev has been updated to
(1)use unidiff (and the correct order of src and target)
(2)put those diffs into a patches dir
(3)remove the minigzip.c from the ws (this one is not included in the file_c
list...)
On Fri, Aug 21, 2009 at 11:09, Xueming Shen wrote:
>
> Martin, webrev has been updated to
>
> (1)use unidiff (and the correct order of src and target)
> (2)put those diffs into a patches dir
> (3)remove the minigzip.c from the ws (this one is not included in the file_c
> list...)
Thanks.
--
Martin, webrev has been updated to
(1)use unidiff (and the correct order of src and target)
(2)put those diffs into a patches dir
(3)remove the minigzip.c from the ws (this one is not included in the
file_c list...)
http://cr.openjdk.java.net/~sherman/zlib123/webrev
Thanks
Sherman
Martin Buc
Martin Buchholz wrote:
I like very much that you are saving local changes in the form of patches
(I've been advocating this style of modification of upstream sources
for a while now), but...
- please generate your patches in "unidiff" form (diff -u)
- the extension ".patch" is, I think, preferabl
I like very much that you are saving local changes in the form of patches
(I've been advocating this style of modification of upstream sources
for a while now), but...
- please generate your patches in "unidiff" form (diff -u)
- the extension ".patch" is, I think, preferable to ".diff"
(or put th
Here is the latest webrev for updating the zlib from the aged 1.1.3 to
the latest version 1.2.3
http://cr.openjdk.java.net/~sherman/zlib123/webrev
Alan, Kumar Martin, thanks for the comments, while I'm continuing
running more tests:-) here are the
reply to your comments/questions.
(1) The ZL
27 matches
Mail list logo
