Skip to content

parser: Fix 3 corner cases #7694

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 4 commits into from
Apr 16, 2025
Merged

parser: Fix 3 corner cases #7694

merged 4 commits into from
Apr 16, 2025

Conversation

drinkcat
Copy link
Contributor

@drinkcat drinkcat commented Apr 8, 2025

This can wait a bit, e.g. after #7656 and #7675 so they don't have to rebase (I don't think there's any direct logical conflict but maybe some context).


uucore: parser: num_parser: Parse "0x"/"0b" as PartialMatch

printf treats "0x" as a partial match of 0 and "x".

uucore: parser: num_parser: Ignore empty exponents

Numbers like 123.15e or 123.15e- should return PartialMatch.

Numbers like e, .e are not valid.

Fixes #7685.

uucore: parser: num_parser: Return error if no digit has been parsed

This is mostly important when parsing digits like . and 0x.
where we should return an error.

Fixes #7684.

Copy link

github-actions bot commented Apr 8, 2025

GNU testsuite comparison:

Skipping an intermittent issue tests/timeout/timeout (passes in this run but fails in the 'main' branch)

@drinkcat
Copy link
Contributor Author

Resolved conflicts.

@sylvestre
Copy link
Contributor

can we have tests in test/by-util/ too ?
thanks
i like having high level integration tests

Copy link

GNU testsuite comparison:

Skip an intermittent issue tests/timeout/timeout (fails in this run but passes in the 'main' branch)

Copy link
Member

@tertsdiepraam tertsdiepraam left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems fine although the Option<BigInt> feels a bit convoluted? I wonder if all this might benefit from not using an iterator but just operating on the slice. I find that to be much easier to reason about usually. I won't mind this being merged though.

@drinkcat
Copy link
Contributor Author

can we have tests in test/by-util/ too ?

Will do (those end-to-end tests were very useful when doing refactoring...)

This seems fine although the Option<BigInt> feels a bit convoluted?

My first instinct (coming from more "classical" languages) was to carry that information in a boolean (digit_parsed?), and then, digits value would only be considered if digit_parsed is true (and the same for the exponent). But, that's... basically what an Option does?

Happy to hear your suggestions though ,-)

I wonder if all this might benefit from not using an iterator but just operating on the slice. I find that to be much easier to reason about usually. I won't mind this being merged though.

This function badly needs some rethinking/splitting, overall. I can look a bit more into it after this (hopefully we're done with most of the big features/bug fixes work now...)

This is mostly important when parsing digits like `.` and `0x.`
where we should return an error.

Fixes uutils#7684.
Numbers like 123.15e or 123.15e- should return PartialMatch.

Numbers like `e`, `.e` are not valid.

Fixes uutils#7685.
printf treats "0x" as a partial match of 0 and "x".
@drinkcat
Copy link
Contributor Author

can we have tests in test/by-util/ too ? thanks i like having high level integration tests

Done!

Copy link

GNU testsuite comparison:

Skipping an intermittent issue tests/misc/stdbuf (passes in this run but fails in the 'main' branch)

@RenjiSann RenjiSann merged commit 349e568 into uutils:main Apr 16, 2025
70 checks passed
@RenjiSann
Copy link
Collaborator

Thanks a lot !

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.

printf: Should not allow numbers with exponents only printf: Should not parse "." as a valid numeric value
4 participants