Thanks to visit codestin.com
Credit goes to github.com

Skip to content

[Form] NumberType: Fix parsing of numbers in exponential notation with negative exponent #57861

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
Aug 7, 2024

Conversation

jbtronics
Copy link
Contributor

@jbtronics jbtronics commented Jul 28, 2024

Q A
Branch? 5.4
Bug fix? yes
New feature? no
Deprecations? no
Issues See below
License MIT

Currently, when inputting a string like "1E-3" into a NumberType leads incorrectly to a result of "0". The correct result would be "0.001", which is also the result, when inputting "1.0E-3".

This is caused by NumberToLocalizedStringTransformer, which assumes that the result must be a integer, if the string does not contain the decimal separator. However, this behavior is incorrect, if the string is in exponential notation with negative exponent.
The NumberFormatter can correctly parse this format, but it needs to be told that the result should be a double (otherwise its gets incorrectly rounded to 0)

To fix this behavior, I added a check for the negative exponential format, which then results in a double result.

@carsonbot
Copy link

Hey!

Thanks for your PR. You are targeting branch "7.1" but it seems your PR description refers to branch "5.4, 6.4, 7.0, and 7.1 for bug fixes".
Could you update the PR description or change target branch? This helps core maintainers a lot.

Cheers!

Carsonbot

@jbtronics jbtronics changed the title [Form] NumberType: Fix parsing of numbers in exponential notation and negative exponent [Form] NumberType: Fix parsing of numbers in exponential notation with negative exponent Jul 28, 2024
@xabbuh
Copy link
Member

xabbuh commented Jul 29, 2024

Is 5.4 not affected by this? Also we need some tests to prevent regressions.

@jbtronics
Copy link
Contributor Author

@xabbuh Yes Symfony 5.4 (and all other currently supported versions) are affected by this bug, as the relevant code parts were not changed for a while.

I also added some tests for the parsing of numbers in e-notation, which was not covered by tests before. These should also prevent regression of this issue.

@OskarStark OskarStark modified the milestones: 7.1, 5.4 Jul 30, 2024
@nicolas-grekas nicolas-grekas changed the base branch from 7.1 to 5.4 August 7, 2024 08:56
@nicolas-grekas nicolas-grekas force-pushed the number-type-e-notation-fix branch from 4eeeb4c to 62c70bd Compare August 7, 2024 08:56
@nicolas-grekas
Copy link
Member

Thank you @jbtronics.

@nicolas-grekas nicolas-grekas merged commit e6337fd into symfony:5.4 Aug 7, 2024
11 of 12 checks passed
This was referenced Aug 30, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants