RFR: 8331485: Odd Results when Parsing Scientific Notation with Large Exponent [v3]
Naoto Sato
naoto at openjdk.org
Mon May 6 18:37:54 UTC 2024
On Mon, 6 May 2024 17:52:07 GMT, Justin Lu <jlu at openjdk.org> wrote:
>> Please review this PR which corrects an edge case bug for java.text.DecimalFormat that causes incorrect parsing results for strings with very large exponent values.
>>
>> When parsing values with large exponents, if the value of the exponent exceeds `Integer.MAX_VALUE`, the parsed value is equal to 0. If the value of the exponent exceeds `Long.MAX_VALUE`, the parsed value is equal to the mantissa. Both results are confusing and incorrect.
>>
>> For example,
>>
>>
>> NumberFormat fmt = NumberFormat.getInstance(Locale.US);
>> fmt.parse(".1E2147483648"); // returns 0.0
>> fmt.parse(".1E9223372036854775808"); // returns 0.1
>> // For comparison
>> Double.parseDouble(".1E2147483648"); // returns Infinity
>> Double.parseDouble(".1E9223372036854775808"); // returns Infinity
>>
>>
>> After this change, both parse calls return `Double.POSITIVE_INFINITY` now.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>
> Address PP for exp > Long.MAX_VALUE + more exp test cases
test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java line 57:
> 55: @ParameterizedTest
> 56: @MethodSource({"largeExponentValues", "smallExponentValues", "bugReportValues", "edgeCases"})
> 57: public void overflowTest(String parseString, Double expectedValue) {
Since this is a regression test, it may be better having both 1-arg parse() and 2-arg parse() tested separately, instead of replacing.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1591405570
More information about the core-libs-dev
mailing list