https://bugs.openjdk.java.net/browse/JDK-8214583
http://cr.openjdk.java.net/~dlong/8214583/webrev
This change includes two new regression test that demonstrate the
problem, and a fix that allows the tests
to pass.
The problem happens when the JIT compiler's escape analysis eliminates
the allo
Hi Jamil,
Thanks for the code review.
Okay, I will go ahead with the comment "fatal() always throws, make the
compiler happy" for this update, and file a new bug and see if we could
make an improvement in the future.
Thanks,
Xuelei
On 12/14/2018 4:16 PM, Jamil Nimeh wrote:
Hi Xuelei, thanks
Hi Xuelei, thanks for the clarification. If you want to keep the
structure as-is, then the comment "fatal() always throws, make the
compiler happy" is fine. I think that's a little more helpful to a
future maintainer who might be new to the code.
Thanks,
--Jamil
On 12/14/2018 1:56 PM, Xue-L
On 12/14/2018 1:46 PM, Xue-Lei Fan wrote:
Hi,
The purpose of combination of the two lines together:
shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "...");
return null; // make the complier happy
is actually for the reading of the code. If one don't know the fatal()
always throw
Hi,
The purpose of combination of the two lines together:
shc.conContext.fatal(Alert.UNEXPECTED_MESSAGE, "...");
return null;// make the complier happy
is actually for the reading of the code. If one don't know the fatal()
always throw an exception (compiler is one of them), he ma
On 12/14/2018 12:26 PM, Anthony Scarpino wrote:
Other than my nit about the “make the compiler happy”, this all looks fine.
It makes sense to me. I will remove the comment while pushing.
For KeyUpdate, shouldn’t it never be null given the suite and protocol are
already known good? I have n
On 12/12/18 10:57 AM, Weijun Wang wrote:
Thanks. Will you please also take a look at the release note
athttps://bugs.openjdk.java.net/browse/JDK-8215293?
I'm not sure about including the second sentence: "In particular, the
algorithm for certificate protection and MacData can be set to "NONE"
Other than my nit about the “make the compiler happy”, this all looks fine.
For KeyUpdate, shouldn’t it never be null given the suite and protocol are
already known good? I have not problem with the check to be cautious even if
it should never happen.
Tony
> On Dec 14, 2018, at 9:00 AM, Xue
My nit is I’d remove the “make compiler happy” comment. If this was something
for Xcomp, I’d understand, but this is standard return value requirement.
Otherwise I’m fine with this
Tony
> On Dec 14, 2018, at 11:49 AM, Jamil Nimeh wrote:
>
> Looks pretty good. I did have one question about a
Looks pretty good. I did have one question about a few of the methods
in KeyShareExtension and PreSharedKeyExtension, specifically where you
return nulls on error branches with the make-compiler-happy comments.
In those cases would it be a bit cleaner to set a byte[] variable to
null at the b
On Fri, Dec 14, 2018 at 02:09:50PM +, Bernd Eckenfels wrote:
> Maybe a comment should point to the description of this pattern (if it
> applies):
> https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5
+1
Do document what initialized/checkInitialized() are about. Now I'm wonde
Hi,
Could I have the fix reviewed?
http://cr.openjdk.java.net/~xuelei/8213782/webrev.00/
The SSLCipher.createReadCipher() and createWriteCipher() could return
null if the cipher is not supported or the cipher is not available for a
certain protocol version. The caller should check the null
Hi,
Please review the update:
http://cr.openjdk.java.net/~xuelei/8214339/webrev.00/
In some cases, the SSLProtocolException or SSLHandshakeException may be
thrown if the underlying socket run into problems. An application may
depends on the exception class for further action, for example r
Maybe a comment should point to the description of this pattern (if it
applies): https://www.oracle.com/technetwork/java/seccodeguide-139067.html#4-5
Gruss
Bernd
Gruss
Bernd
--
http://bernd.eckenfels.net
Von: security-dev im Auftrag von
Valerie Peng
Gesendet:
14 matches
Mail list logo
