Re: RFR: 8331485: Odd Results when Parsing Scientific Notation with Large Exponent [v3]

2024-05-06 Thread Naoto Sato 
On Mon, 6 May 2024 17:52:07 GMT, Justin Lu  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

Re: RFR: 8331485: Odd Results when Parsing Scientific Notation with Large Exponent [v3]

2024-05-06 Thread Justin Lu 
> 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

-

Changes:
  - all: https://git.openjdk.org/jdk/pull/19075/files
  - new: https://git.openjdk.org/jdk/pull/19075/files/bc391f96..25782781

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19075&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19075&range=01-02

  Stats: 41 lines in 4 files changed: 28 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/19075.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19075/head:pull/19075

PR: https://git.openjdk.org/jdk/pull/19075