<i18n dev> RFR: 8331485: Odd Results when Parsing Scientific Notation with Large Exponent [v4]

Axel Hauschulte duke at openjdk.org
Mon May 6 19:50:55 UTC 2024


On Mon, 6 May 2024 18:55:25 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:
> 
>   Check both parse methods

test/jdk/java/text/Format/DecimalFormat/LargeExponentsTest.java line 150:

> 148:                 // Long.MIN_VALUE
> 149:                 Arguments.of("1.23E-9223372036854775808", 0.0)
> 150:         );

I would suggest adding one more test case to the edge cases:

Arguments.of("0.0123E-2147483648", 0.0)

This will test the adjustment of the `digits.decimalAt` field for an exponent that is within the range of integer, but due to the mantissa not being in its standardized form an overflow will occure non the less.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19075#discussion_r1591480295


More information about the i18n-dev mailing list