Hi,
Base64GetEncoderTest does not need to test the negative values more than
once.
Otherwise, looks fine.
Roger
On 1/30/2018 9:31 AM, Alan Bateman wrote:
On 29/01/2018 17:52, Xueming Shen wrote:
Actually I have a dedicated test case for "mime encoder maxlen".
On 29/01/2018 17:52, Xueming Shen wrote:
Actually I have a dedicated test case for "mime encoder maxlen".
*test/jdk/java/util/Base64/Base64GetEncoderTest.java*
I have updated it to test the negative and the < 4 maxlen.
http://cr.openjdk.java.net/~sherman/8176379/webrev/
webrev has been
Hi,
Looks good.
Base64.java: line 120 typo: "outputut" -> "output"
Roger
On 1/29/2018 1:20 PM, Paul Sandoz wrote:
+1
We will require a CSR for the minor adjustment to the specification.
Paul.
On Jan 29, 2018, at 9:52 AM, Xueming Shen wrote:
On 01/26/2018
+1
We will require a CSR for the minor adjustment to the specification.
Paul.
> On Jan 29, 2018, at 9:52 AM, Xueming Shen wrote:
>
> On 01/26/2018 03:53 PM, Paul Sandoz wrote:
>>
>> Base64
>> —
>>
>> 138 lineLength = lineLength >> 2 << 2;
>>
>> I know the code was
On 01/26/2018 03:53 PM, Paul Sandoz wrote:
Base64
—
138 lineLength = lineLength>> 2<< 2;
I know the code was shuffled up but i find the following clearer in terms of
bit manipulation:
// Round down to nearest mulitple of 4
lineLength&= ~0b11
sure, we can go the straightforward bit
Base64
—
138 lineLength = lineLength >> 2 << 2;
I know the code was shuffled up but i find the following clearer in terms of
bit manipulation:
// Round down to nearest mulitple of 4
lineLength &= ~0b11
TestBase64
—
Is there a test passing in a negative value for len?
Thanks,
Paul.
>
Hi,
Please help review the change for JDK-8176379
issue: https://bugs.openjdk.java.net/browse/JDK-8176379
webrev: http://cr.openjdk.java.net/~sherman/8176379/webrev
It appears the spec is somewhat misleading and/or incorrect in this corner
case. And the implementation of the mime type encoder