On Mon, 29 Sep 2025 21:38:28 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. This pull request has now been integrated. Changeset: 6b72b778 Author: Justin Lu <[email protected]> URL: https://git.openjdk.org/jdk/commit/6b72b778039afce0e25986114d15dd29a6786529 Stats: 44 lines in 2 files changed: 40 ins; 0 del; 4 mod 6177299: [Fmt-Nu] NumberFormat.getPercentInstance() does not work correctly Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/27563
