float: Fix panic at max exponential precision by cdown · Pull Request #154052 · rust-lang/rust

cdown · 2026-03-18T18:12:50Z

Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point).

This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce02 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first.

As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX.

A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter.

Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic.

This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.

rustbot · 2026-03-18T18:20:20Z

r? @Mark-Simulacrum

rustbot has assigned @Mark-Simulacrum.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Why was this reviewer chosen?

The reviewer was selected based on:

Owners of files modified in this PR: @scottmcm, libs
@scottmcm, libs expanded to 8 candidates
Random selection from Mark-Simulacrum, scottmcm

rustbot · 2026-03-20T06:23:36Z

Some changes occurred in float parsing

cc @tgross35

rustbot · 2026-03-23T02:25:46Z

Reminder, once the PR becomes ready for a review, use @rustbot ready.

Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point). This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce02 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first. As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX. A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter. Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic. This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.

rustbot · 2026-04-04T12:46:54Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

cdown · 2026-04-04T12:48:23Z

@rustbot ready

Mark-Simulacrum · 2026-04-04T16:06:42Z

@bors r+

rust-bors · 2026-04-04T16:06:45Z

📌 Commit 2ae6c61 has been approved by Mark-Simulacrum

It is now in the queue for this repository.

…uwer Rollup of 6 pull requests Successful merges: - #147552 ([Debugger Visualizers] Optimize lookup behavior) - #154052 (float: Fix panic at max exponential precision) - #154706 (fix compilation of time/hermit.rs) - #154707 (Make `substr_range` and `subslice_range` return the new `Range` type) - #154767 (triagebot: roll library reviewers for `{coretests,alloctests}`) - #154797 (bootstrap: Include shorthand aliases in x completions)

Rollup merge of #154052 - cdown:cdown/2026-03-19/precision, r=Mark-Simulacrum float: Fix panic at max exponential precision Rust's formatting machinery allows precision values of up to u16::MAX. Exponential formatting works out the number of significant digits to use by adding one (for the integral digit before the decimal point). This previously used usize precision, so the maximum validated precision did not overflow, but in commit fb9ce02 ("Limit formatting width and precision to 16 bits.") the precision type was narrowed to u16 without widening that addition first. As a result an exponential precision value of 65535 is no longer handled correctly, because the digit count wraps to 0, and thus "{:.65535e}" panics in flt2dec::to_exact_exp_str with "assertion failed: ndigits > 0". Other formats (and the parser) accept values up to u16::MAX. A naive fix would be to widen that addition back to usize, but that still does not properly address 16-bit targets, where usize is only guaranteed to be able to represent values up to u16::MAX. The real issue is that this internal API is expressed in the wrong units for the formatter. Fix this by changing exact exponential formatting to take fractional digits internally as well, and compute the temporary significant digit bound only when sizing the scratch buffer. To support that let's also make formatted length accounting saturate so that extremely large rendered outputs do not reintroduce overflows in padding logic. This preserves the existing intent and keeps FormattingOptions compact while making formatting work consistently again.

…uwer Rollup of 6 pull requests Successful merges: - rust-lang/rust#147552 ([Debugger Visualizers] Optimize lookup behavior) - rust-lang/rust#154052 (float: Fix panic at max exponential precision) - rust-lang/rust#154706 (fix compilation of time/hermit.rs) - rust-lang/rust#154707 (Make `substr_range` and `subslice_range` return the new `Range` type) - rust-lang/rust#154767 (triagebot: roll library reviewers for `{coretests,alloctests}`) - rust-lang/rust#154797 (bootstrap: Include shorthand aliases in x completions)

rustbot assigned Mark-Simulacrum Mar 18, 2026

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. T-libs Relevant to the library team, which will review and decide on the PR/issue. labels Mar 18, 2026

cdown force-pushed the cdown/2026-03-19/precision branch 2 times, most recently from 71fe342 to d57cfdfCompare March 19, 2026 03:32

hkBst suggested changes Mar 19, 2026
View reviewed changes

Comment threadlibrary/core/src/fmt/float.rs Outdated

cdown force-pushed the cdown/2026-03-19/precision branch from d57cfdf to 77f6ba6Compare March 20, 2026 06:23

cdown requested a review from hkBst March 20, 2026 06:23

cdown commented Mar 20, 2026
View reviewed changes

Comment threadlibrary/core/src/num/imp/fmt.rs

Mark-Simulacrum requested changes Mar 23, 2026
View reviewed changes

Comment threadlibrary/core/src/num/imp/flt2dec/mod.rs
Comment threadlibrary/core/src/num/imp/fmt.rs

rustbot removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Mar 23, 2026

rustbot added the S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. label Mar 23, 2026

cdown force-pushed the cdown/2026-03-19/precision branch from 77f6ba6 to 2ae6c61Compare April 4, 2026 12:46

rustbot added S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Apr 4, 2026

rust-borsBot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Apr 4, 2026

JonathanBrouwer mentioned this pull request Apr 4, 2026
Rollup of 6 pull requests #154824
Merged

rust-borsBot merged commit f523f84 into rust-lang:mainApr 5, 2026
11 checks passed

rustbot added this to the 1.96.0 milestone Apr 5, 2026

Navigation Menu

Uh oh!

Uh oh!

float: Fix panic at max exponential precision - #154052

float: Fix panic at max exponential precision#154052
rust-bors[bot] merged 1 commit into
rust-lang:mainfrom
cdown:cdown/2026-03-19/precision

cdown commented Mar 18, 2026•
edited
Loading

Uh oh!

rustbot commented Mar 18, 2026

Uh oh!

Uh oh!

rustbot commented Mar 20, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Mar 23, 2026

Uh oh!

rustbot commented Apr 4, 2026

Uh oh!

cdown commented Apr 4, 2026

Uh oh!

Mark-Simulacrum commented Apr 4, 2026

Uh oh!

rust-borsBot commented Apr 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Uh oh!

Uh oh!

Conversation

cdown commented Mar 18, 2026• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

rustbot commented Mar 18, 2026

Uh oh!

Uh oh!

rustbot commented Mar 20, 2026

Uh oh!

Uh oh!

Uh oh!

Uh oh!

rustbot commented Mar 23, 2026

Uh oh!

rustbot commented Apr 4, 2026

Uh oh!

cdown commented Apr 4, 2026

Uh oh!

Mark-Simulacrum commented Apr 4, 2026

Uh oh!

rust-borsBot commented Apr 4, 2026

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

cdown commented Mar 18, 2026•
edited
Loading