On Sun, Aug 23, 2009 at 21:56, Xueming Shen xueming.s...@sun.com wrote:
Martin Buchholz wrote:
On Sat, Aug 22, 2009 at 20:37, Xueming Shenxueming.s...@sun.com wrote:
-
31 @@ -39,7 +63,7 @@
32 typedef unsigned int u4;
33 #else
34 # if (ULONG_MAX ==
* 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, you
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
Changeset: dbcc1f13e4fd
Author:weijun
Date: 2009-08-24 18:37 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dbcc1f13e4fd
6875033: regression: test of 6867665 fail
Reviewed-by: xuelei
! test/sun/security/krb5/ktab/HighestKvno.java
Changeset: d954cd279188
Author:ohair
Date: 2009-08-24 09:57 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/d954cd279188
6853636: Fix warnings in jdwpgen, add jdwpgen NetBeans project
Reviewed-by: andrew, alanb, tbell, swamyv
! .hgignore
+ make/netbeans/jdwpgen/build.xml
+
This is a different issue. I would prefer to separate the to upgrade to
zlib 1.2.3 and
to use host platform zlib on linux, if preferable into two different
tasks. We tend to
try to put too many similar things into one project and end up missing
the primary
goal:-) Given the zlib is so
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
On Mon, Aug 24, 2009 at 11:06, Xueming Shenxueming.s...@sun.com 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 is
On Mon, Aug 24, 2009 at 11:16, Xueming Shenxueming.s...@sun.com 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
On Mon, Aug 24, 2009 at 10:17, Xueming Shenxueming.s...@sun.com wrote:
This is a different issue. I would prefer to separate the to upgrade to
zlib 1.2.3 and
to use host platform zlib on linux, if preferable into two different
tasks. We tend to
try to put too many similar things into one
Changeset: dd997cc0c823
Author:vinnie
Date: 2009-08-24 18:37 +0100
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dd997cc0c823
6872048: bad private keys are generated for 2 specific ECC curves
Reviewed-by: wetmore
! src/share/native/sun/security/ec/ec.c
!
Martin Buchholz wrote:
On Mon, Aug 24, 2009 at 11:16, Xueming Shenxueming.s...@sun.com 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
On Mon, Aug 24, 2009 at 14:21, Xueming Shenxueming.s...@sun.com 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
Changeset: c863e90091ee
Author:jjg
Date: 2009-08-24 14:38 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/langtools/rev/c863e90091ee
6869216: testgetallmembers should consistently use correct filemanager
Reviewed-by: darcy
!
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 15:24, Xueming Shenxueming.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
16 matches
Mail list logo
