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
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
! test/tools/javac/processing/model/testgetallmembers/Main.ja
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
Martin Buchholz wrote:
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 d
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
! test/sun/security/ec/Test
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
On Mon, Aug 24, 2009 at 10:17, Xueming Shen 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 project and en
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
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 "imp
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
+ ma
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
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)
17 matches
Mail list logo
