RFR: JDK-8197988, mach5 T2 test javax/net/ssl/interop/ClientHelloChromeInterOp.java failed after JDK-8164278

[Alan Bateman]

On 15/02/2018 07:49, Xueming Shen wrote:
> Hi,
>
> Please help review the change for  JDK-819798
>
> issue: https://bugs.openjdk.java.net/browse/JDK-8197988
> webrev: http://cr.openjdk.java.net/~sherman/8197988/webrev
>
> The change for JDK-8164278 caused a decoding regression. A Tier2
> test case,  javax/net/ssl/interop/ClientHelloChromeInterOp.java, that
> uses mime-base64-decoder failed.
>
> The "condition" that triggers the decoding to go the fast path is 
> incorrect in
> the code pushed for JDK-819798.
>
> The intent here is to only start/try the fast path when we are at the 
> beginning
> of a 4-byte legal base64 unit. The correct/appropriate check is to see if
> shiftto == 18, which means the decoder is still at the beginning of 
> 4-byte
> unit. ( bits == 0 is a false indicator, as bits might include decoded 
> byte value of
> 0). The fix is a relatively easy/one line change.
This looks okay. Should we create another issue to add more tests in 
this area to avoid the SSL code finding issues in this area again.

-Alan