Skip to content

Reject trailing characters in DecimalLocaleConverter.parse#399

Merged
garydgregory merged 2 commits into
apache:masterfrom
rootvector2:decimal-locale-trailing-chars
Jun 21, 2026
Merged

Reject trailing characters in DecimalLocaleConverter.parse#399
garydgregory merged 2 commits into
apache:masterfrom
rootvector2:decimal-locale-trailing-chars

Conversation

@rootvector2

Copy link
Copy Markdown
Contributor

DecimalLocaleConverter.parse calls DecimalFormat.parse(String), which stops at the first character it cannot read and silently drops the rest, so a locale numeric conversion of 123abc returns 123 and 42 OR 1=1 returns 42. Every numeric locale converter (Byte/Short/Integer/Long/Float/Double/BigDecimal/BigInteger) routes through this one method, while the sibling DateLocaleConverter and the non-locale NumberConverter already reject leftover input with a ParsePosition check. Found by comparing the locale number parsers against DateLocaleConverter; switched to that same check so the whole string must be consumed.

  • Read the contribution guidelines for this project.
  • Read the ASF Generative Tooling Guidance if you use Artificial Intelligence (AI).
  • I used AI to create any part of, or all of, this pull request. Which AI tool was used to create this pull request, and to what extent did it contribute?
  • Run a successful build using the default Maven goal with mvn; that's mvn on the command line by itself.
  • Write unit tests that match behavioral changes, where the tests fail if the changes to the runtime are not applied. This may not always be possible, but it is a best practice.
  • Write a pull request description that is detailed enough to understand what the pull request does, how, and why.
  • Each commit in the pull request should have a meaningful subject line and body.

DecimalFormat.parse(String) stops at the first unparsable character and
discards the rest, so numeric locale conversion accepted trailing input.
Parse with a ParsePosition and require the whole string to be consumed,
matching DateLocaleConverter and NumberConverter.
@garydgregory garydgregory changed the title reject trailing characters in DecimalLocaleConverter.parse Reject trailing characters in DecimalLocaleConverter.parse Jun 21, 2026
@garydgregory

Copy link
Copy Markdown
Member

Hello @rootvector2
Please review the failing tests. TY!

The (B) cases asserted DecimalFormat's partial parse of wrong-format input; with the whole string now required, those inputs return the converter default. Updated the expected values and now-stale comments.
@rootvector2

Copy link
Copy Markdown
Contributor Author

Those were the existing (B) assertions that pinned DecimalFormat's partial parse of wrong-format input (e.g. 1,234.56 -> 1.234). Now that the whole string has to be consumed, those inputs fall through to the converter default, so I updated the expected values and the now-stale comments across the numeric locale converter tests. mvn test is green.

@garydgregory garydgregory merged commit 1b86e98 into apache:master Jun 21, 2026
7 of 9 checks passed
@garydgregory

Copy link
Copy Markdown
Member

Thank you @rootvector2
Merged 🚀
Would you mind porting this fix to the 1.X branch?

@rootvector2

Copy link
Copy Markdown
Contributor Author

Ported to 1.X in #400. Same ParsePosition check, plus the (B) test assertions updated since the wrong-format inputs now fall through to the default.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants