Repository navigation
Conversation
bd_to_string_exp_with_prec rounded with BigDecimal::with_prec, which rounds halves up, so %e, %E, %g and %G turned an exact tie such as %.0e of 2.5 into 3e+00. C printf rounds ties to even, and %f already did so, giving 2e+00. Round with with_precision_round(.., RoundingMode::HalfEven) instead. Fixes uutils#15662
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.
| // (e.g. 9995 rounded to 3 digits => 1000 * 10^1, but we want 100 * 10^2), we compensate | ||
| // for that later. | ||
| let bd_round = bd.with_prec(precision as u64); | ||
| let precision_nz = NonZeroU64::new(precision as u64).expect("precision must be at least 1"); |
There was a problem hiding this comment.
could we avoid the expect? unwrap_or(NonZeroU64::MIN) would do, or take a NonZeroU64 param
There was a problem hiding this comment.
Done, it now uses unwrap_or(NonZeroU64::MIN).
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.
Fixes #15662
bd_to_string_exp_with_precrounded withBigDecimal::with_prec, which rounds halves up. Every%e/%E/%g/%Gconversion goes through it, in bothprintfandseq -f, so exact ties rounded away from zero.%fformats throughBigDecimal'sDisplay, which already rounds half to even, so%.0fand%.0eof 2.5 gave different answers.This switches to
with_precision_round(.., RoundingMode::HalfEven). It produces the extra digit on overflow (9.5 →1e+01) the same waywith_precdid, so the existing correction still applies. Both callers pass a precision of at least 1, whichNonZeroU64now records.Tests:
num_format.rs: ties, values just above a tie, and the overflow case for both scientific and shortest formatting.test_printfandtest_seqcases. I checked every expected value against GNU coreutilsprintf/seq9.4, and the new integration tests fail onmain.printf,seq,csplit,dd,du,echoandls(all users ofuucore's format feature) pass. The one exception istest_du_inaccessible_directory, which also fails onmainwhen run as root.cargo clippy -p uucore --features format --all-targets -- -D warningsandcargo fmt --checkare clean.I wrote this from the behaviour described in the issue and bigdecimal's API, without looking at GNU's code.