gh-158446: Reject float format precision near INT_MAX by gpshead · Pull Request #158474 · python/cpython

gpshead · 2026-09-30T03:30:36Z

PyOS_double_to_string() now raises ValueError("precision too big") for precisions above INT_MAX - 1024, matching what the format parsers already do above INT_MAX. Buffer size computations in pystrtod.c and dtoa.c add a few hundred to the precision using int / Py_ssize_t arithmetic and could wrap for such values, leading to a crash or incorrect output.

Also harden _Py_dg_dtoa() and rv_alloc() so their size arithmetic stays in range for any C caller.

This was reviewed and approved via the PSRT in a report which we'll make public soon as security releases are about to be cut tomorrow.

Issue: Reject float format precision near INT_MAX #158446

PyOS_double_to_string() now raises ValueError("precision too big") for precisions above INT_MAX - 1024, matching what the format parsers already do above INT_MAX. Buffer size computations in pystrtod.c and dtoa.c add a few hundred to the precision using int / Py_ssize_t arithmetic and could wrap for such values, leading to a crash or incorrect output. Also harden _Py_dg_dtoa() and rv_alloc() so their size arithmetic stays in range for any C caller.

…ording Make the PyOS_double_to_string() precision check symmetric so that C callers passing a huge negative precision cannot reach the remaining precision arithmetic either. Reword the NEWS entry: the limit applies to float and complex formatting regardless of presentation type or value.

Note the dtoa.c deviations in its header list, cross-reference the shared bound between dtoa.c and pystrtod.c, PEP 7 brace placement, and wrap a long test comment. No functional change.

miss-islington-app · 2026-09-30T05:22:42Z

Thanks @gpshead for the PR 🌮🎉.. I'm working now to backport this PR to: 3.10, 3.11, 3.12, 3.13, 3.14, 3.15.
🐍🍒⛏🤖

bedevere-app · 2026-09-30T05:22:57Z

GH-158476 is a backport of this pull request to the 3.15 branch.

bedevere-app · 2026-09-30T05:23:06Z

GH-158477 is a backport of this pull request to the 3.14 branch.

bedevere-app · 2026-09-30T05:23:11Z

GH-158478 is a backport of this pull request to the 3.13 branch.

miss-islington-app · 2026-09-30T05:23:15Z

Sorry, @gpshead, I could not cleanly backport this to 3.10 due to a conflict.
Please backport using cherry_picker on command line.

cherry_picker b7b4f3ecf2fce4451ee1a8e8c1b6e92dea60ce3d 3.10

bedevere-app · 2026-09-30T05:23:19Z

GH-158479 is a backport of this pull request to the 3.12 branch.

bedevere-app · 2026-09-30T05:23:27Z

GH-158480 is a backport of this pull request to the 3.11 branch.

bedevere-app · 2026-09-30T05:35:32Z

GH-158482 is a backport of this pull request to the 3.10 branch.

…) (#158478) gh-158446: Reject float format precision near INT_MAX (GH-158474) Formatting a float or complex with a precision within about 1000 of INT_MAX could crash or produce incorrect output. PyOS_double_to_string() now raises ValueError("precision too big") for such precisions, as the format string parsers already do for precisions above INT_MAX. The limit applies regardless of presentation type or value, so a few calls that previously succeeded (inf, nan, or 'g' with such a precision) now raise as well. (cherry picked from commit b7b4f3e) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

…) (#158476) gh-158446: Reject float format precision near INT_MAX (GH-158474) Formatting a float or complex with a precision within about 1000 of INT_MAX could crash or produce incorrect output. PyOS_double_to_string() now raises ValueError("precision too big") for such precisions, as the format string parsers already do for precisions above INT_MAX. The limit applies regardless of presentation type or value, so a few calls that previously succeeded (inf, nan, or 'g' with such a precision) now raise as well. (cherry picked from commit b7b4f3e) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

…) (#158477) gh-158446: Reject float format precision near INT_MAX (GH-158474) Formatting a float or complex with a precision within about 1000 of INT_MAX could crash or produce incorrect output. PyOS_double_to_string() now raises ValueError("precision too big") for such precisions, as the format string parsers already do for precisions above INT_MAX. The limit applies regardless of presentation type or value, so a few calls that previously succeeded (inf, nan, or 'g' with such a precision) now raise as well. (cherry picked from commit b7b4f3e) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com>

…) (#158479) * gh-158446: Reject float format precision near INT_MAX (GH-158474) Formatting a float or complex with a precision within about 1000 of INT_MAX could crash or produce incorrect output. PyOS_double_to_string() now raises ValueError("precision too big") for such precisions, as the format string parsers already do for precisions above INT_MAX. The limit applies regardless of presentation type or value, so a few calls that previously succeeded (inf, nan, or 'g' with such a precision) now raise as well. (cherry picked from commit b7b4f3e) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> * gh-158446: Fix the new test_format test on 3.12 test_format.py does not import import_module on this branch. Import INT_MAX from _testcapi directly, as the neighboring test does. --------- Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>

…) (#158482) Formatting a float or complex with a precision within about 1000 of INT_MAX could crash or produce incorrect output. PyOS_double_to_string() now raises ValueError("precision too big") for such precisions, as the format string parsers already do for precisions above INT_MAX. The limit applies regardless of presentation type or value, so a few calls that previously succeeded (inf, nan, or 'g' with such a precision) now raise as well. (cherry picked from commit b7b4f3e)

…) (#158480) * gh-158446: Reject float format precision near INT_MAX (GH-158474) Formatting a float or complex with a precision within about 1000 of INT_MAX could crash or produce incorrect output. PyOS_double_to_string() now raises ValueError("precision too big") for such precisions, as the format string parsers already do for precisions above INT_MAX. The limit applies regardless of presentation type or value, so a few calls that previously succeeded (inf, nan, or 'g' with such a precision) now raise as well. (cherry picked from commit b7b4f3e) Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> * gh-158446: Fix the new test_format test on 3.11 test_format.py does not import import_module on this branch. Import INT_MAX from _testcapi directly, as the neighboring test does. --------- Co-authored-by: Gregory P. Smith <68491+gpshead@users.noreply.github.com> Co-authored-by: Gregory P. Smith <greg@krypto.org>

gpshead added 3 commits September 29, 2026 18:17

pythongh-158446: Address review nits

f86460b

Note the dtoa.c deviations in its header list, cross-reference the shared bound between dtoa.c and pystrtod.c, PEP 7 brace placement, and wrap a long test comment. No functional change.

bedevere-app Bot mentioned this pull request Sep 30, 2026

Reject float format precision near INT_MAX #158446

Closed

bedevere-app Bot added the awaiting core review label Sep 30, 2026

gpshead added release-blocker and removed awaiting core review labels Sep 30, 2026

github-project-automation Bot added this to Release and Deferred blockers 🚫 Sep 30, 2026

gpshead self-assigned this Sep 30, 2026

gpshead requested review from JelleZijlstra and Yhg1s September 30, 2026 03:32

JelleZijlstra approved these changes Sep 30, 2026

View reviewed changes

bedevere-app Bot added the awaiting merge label Sep 30, 2026

gpshead enabled auto-merge (squash) September 30, 2026 04:48

Merge branch 'main' into dtoa-precision-limit

6e7a890

gpshead merged commit b7b4f3e into python:main Sep 30, 2026
54 checks passed

bedevere-app Bot removed the awaiting merge label Sep 30, 2026

bedevere-app Bot removed the needs backport to 3.15 pre-release feature fixes, bugs and security fixes label Sep 30, 2026

bedevere-app Bot removed the needs backport to 3.14 bugs and security fixes label Sep 30, 2026

bedevere-app Bot removed the needs backport to 3.13 only security fixes label Sep 30, 2026

bedevere-app Bot removed the needs backport to 3.12 only security fixes label Sep 30, 2026

bedevere-app Bot removed the needs backport to 3.11 only security fixes label Sep 30, 2026

bedevere-app Bot removed the needs backport to 3.10 only security fixes label Sep 30, 2026

Navigation Menu

Uh oh!

gh-158446: Reject float format precision near INT_MAX - #158474

gh-158446: Reject float format precision near INT_MAX#158474
gpshead merged 4 commits into
python:mainfrom
gpshead:dtoa-precision-limit

gpshead commented Sep 30, 2026 •

edited

Loading

Uh oh!

Uh oh!

miss-islington-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

miss-islington-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Uh oh!

Conversation

gpshead commented Sep 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

miss-islington-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

miss-islington-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

bedevere-app Bot commented Sep 30, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

gpshead commented Sep 30, 2026 •

edited

Loading