On Tue, 30 Sep 2025 17:54:21 GMT, Justin Lu <[email protected]> wrote:
>> Please review this PR which corrects an edge case bug for `DecimalFormat` >> parsing when a multiplier is applied. >> >> This issue applies to any parsed Strings whose resultant double value is >> rounded to _9.223372036854776E18_ after the multiplier is applied. The >> returned value is incorrectly given as `Long.MAX_VALUE` when it should be >> returned as the double _9.223372036854776E18_. >> >> For example, the String _"922,337,203,685,477,600,000%"_ is first parsed as >> _9.223372036854776E20_, after which the multiplier is then applied to give >> _9.223372036854776E18_. The original code evaluates `9.223372036854776E18 == >> (double)(long)9.223372036854776E18` as true, leading to the long >> representation returned. >> >> The double value should first be checked if it is within the long min/max >> range before being checked if it can be represented as a long. Note that the >> check should be inclusive, as during the comparison, `Long.MAX_VALUE` is >> promoted to _9.223372036854776E18_. Thus _9.223372036854775E18_ correctly >> compares as false, and all doubles above compare as true. > > Justin Lu has updated the pull request incrementally with one additional > commit since the last revision: > > Naoto review - move test to NR.java Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27563#pullrequestreview-3286169680
