Max,
I think about the readBERInternal() more, would you like add more robust
codes?
1. checking that the tag code is less than 30;
2. checking that the tag form is constructed for indef-length.
Otherwise, looks fine for me.
Andrew
Weijun Wang wrote:
The new webrev is at
http://cr.openjdk.j
The new webrev is at
http://cr.openjdk.java.net/~weijun/6813340/webrev.03
Changes compared to last webrev is:
diff -r 59db2c7c37fa
src/share/classes/sun/security/provider/X509Factory.java
--- a/src/share/classes/sun/security/provider/X509Factory.java
+++ b/src/share/classes/sun/security/provider/
Changeset: dc3865883a5a
Author:weijun
Date: 2009-05-26 10:12 +0800
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/dc3865883a5a
6844887: NPE in TextCallbackHandler
Reviewed-by: xuelei
! src/share/classes/com/sun/security/auth/callback/TextCallbackHandler.java
+ test/com/sun/securit
Brad Wetmore wrote:
There was a problem where the tl and tl-gate got out of sync and was
fixed around 12:35 this afternoon. I don't know if it's the cause of
your problem.
The "hg pull" still did not work for me. but the "hg clone" works now.
Thanks,
Andrew
brad
Xuelei Fan wrote:
$ hg
There was a problem where the tl and tl-gate got out of sync and was
fixed around 12:35 this afternoon. I don't know if it's the cause of
your problem.
brad
Xuelei Fan wrote:
$ hg pull
pulling from http://hg.openjdk.java.net/jdk7/tl/jdk
searching for changes
adding changesets
adding manife
Changeset: 206d73d299d4
Author:jccollet
Date: 2009-05-25 22:27 +0200
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/206d73d299d4
6349566: java.net.CookieManager doesn't set default domain
Summary: Enforce default domain in CookieManager
Reviewed-by: michaelm
! src/share/classes/ja
Changeset: 3994c5c669cb
Author:xlu
Date: 2009-05-24 16:35 -0700
URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/3994c5c669cb
6806261: BigDecimal.longValueExact() method throws NullPointerException
Summary: add various tests to test the change to 6622432
Reviewed-by: darcy
+ test/ja
Xuelei Fan wrote:
t to support indefinite-length, I think you can simply keep reading
until get two zero bytes.
As I understand, "0x80 0x06 0x07 0x01 0x00 0x00" is not an indef-len
BER.
You're right, it is not a valid indef-len BER. I will look twice of
readBERInternal() tomorrow.
The
Max (Weijun) Wang wrote:
3. 584 ~ EOF
You assume that the tag occupy only one byte, that's incorrect, the
tag would occupy more than one byte when it is bigger than 30. The
assume would make the following length parser code incorrect.
You assume that the end of indefinite length is only one
3. 584 ~ EOF
You assume that the tag occupy only one byte, that's incorrect,
the tag would occupy more than one byte when it is bigger than 30.
The assume would make the following length parser code incorrect.
You assume that the end of indefinite length is only one zero
byte, that's incor
Max (Weijun) Wang wrote:
On May 25, 2009, at 6:47 PM, Xuelei Fan wrote:
1.
116 byte[] buffer = new byte[length];
I would like to use a fixed length, such as 1024, for memory saving
for large data. Just a very very personal preference.
I see what you mean. My attempt was read it i
On May 25, 2009, at 6:47 PM, Xuelei Fan wrote:
1.
116 byte[] buffer = new byte[length];
I would like to use a fixed length, such as 1024, for memory saving
for large data. Just a very very personal preference.
I see what you mean. My attempt was read it in a single shot. Will
thi
1.
116 byte[] buffer = new byte[length];
I would like to use a fixed length, such as 1024, for memory saving for
large data. Just a very very personal preference.
2. 562 ~ 567
You assume that the end character of a line is the same for all lines.
That's OK, I just worry about the situ
13 matches
Mail list logo
