RFR: 8251989: Hex formatting and parsing utility [v12]
Roger Riggs
rriggs at openjdk.java.net
Tue Dec 1 16:11:04 UTC 2020
On Tue, 1 Dec 2020 10:37:40 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:
>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>>
>> Clarified hexadecimal characters used in converting from characters to values to be strictly 0-9, a-f, and A-F.
>> Added a test to verify isHexDigit and fromHexDigit for the entire range of chars
>
> src/java.base/share/classes/java/util/HexFormat.java line 436:
>
>> 434: if (delimiter.isEmpty()) {
>> 435: // Allocate the byte array and fill in the hex pairs for each byte
>> 436: rep = new byte[length * 2];
>
> What if `length * 2` overflows?
It should produce an OOME, at the moment would throw NegativeArraySize.
Same below, will add an explicit check and throw.
> src/java.base/share/classes/java/util/HexFormat.java line 516:
>
>> 514:
>> 515: int valueChars = prefix.length() + 2 + suffix.length();
>> 516: int stride = valueChars + delimiter.length();
>
> Unlikely - but there's still a possibility of overflow in these two lines?
> I wonder if those should be checked at construction time - and an IAE thrown if someone tried to create a HexFormat with unreasonable prefix/suffix/delimiters?
> Otherwise maybe use Math.addExact()...
Using long for the intermediate results will avoid the issue.
With maximum prefix or suffix and maximum length string, one of the exceptions
for length or missing prefix or suffix would throw.
The computation for the output byte array can revert to int after the divide by stride.
> src/java.base/share/classes/java/util/HexFormat.java line 741:
>
>> 739: /**
>> 740: * Returns the sixteen hexadecimal characters for the {@code long} value
>> 741: * considering it to be unsigned.
>
> What does this means? And why is it necessary for long when it wasn't necessary for other signed types (byte, short, int). I'd vote for removing `considering it to be unsigned` there - or else add it everywhere else, but then you would have to explain what it means and what you would print if you considered it signed.
Will remove. All java primitive types are signed. When formatted, there is no representation of the sign.
-------------
PR: https://git.openjdk.java.net/jdk/pull/482
More information about the core-libs-dev
mailing list