Repository navigation
numfmt: refuse a value too large to print when it has a suffix - #15672
jayhemnani9910 wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
|
Binary size comparison: |
--from=si 1Y printed 999999999999999983222784, an f64 rounding of 10^24; GNU stops at 10^19 and exits 2, as numfmt already did for numbers without a suffix. The message names the precision only when there is one and prints the value like %g ('1/20', '0/40'), as GNU does.
7d90bc4 to
1c9e428
Compare
There was a problem hiding this comment.
Copilot was unable to review this pull request because the user who requested the review has insufficient remaining quota.
An organization owner can choose the repository organization as the billing source for reviews requested by members with a paid Copilot license. Learn about Copilot code review billing. Review the Copilot code review billing settings.
A number read with a suffix is not checked against the size limit for printing, so numfmt prints a rounded float instead of failing:
Same for
10E,1Z,1R,1Q,--from=auto 1Zi, and with--format=%.1f. Numbers written out in full were already refused; a suffixed value takes the float path intransform_to, which had no check. It now gets the same one (value times 10^precision against 10^19) when there is no--to.The message also follows GNU in two details: without a precision it is
value too large to be printed: '1e+19'(it saidvalue/precision ... '1e+19/0'), and the value is printed like%g, so1and0show as1and0instead of1e+0and0e+0.Two existing expectations change:
test_format_precision_too_large_on_zeroexpected'0e+0/40'(GNU:'0/40'), and--format=%.65536f 1.5, added in #13514 to stop a panic, expected2; GNU refuses it with'1.5/65536', and so does this branch, still without a panic.New tests
test_value_with_suffix_too_large_to_printandtest_value_too_large_without_precision; they and the updated zero case fail on main. The numfmt tests pass (172), clippy is clean. 34 inputs around the limit (suffixes, negative values,--formatprecisions,--to-unit,--from-unit,--invalid=warn, fields, padding) give the same output and exit code as GNU 9.7.