`sys.set_int_max_str_digits` limit is not enforced for large integers

[bell-bot]

Bug report

Bug description:

Description

The sys.set_int_max_str_digits() function appears to not enforce the configured limit when converting a very large integer to a string. This could potentially bypass the intended denial-of-service protection that the limit is designed to provide.

When setting a limit, it is expected that any integer-to-string conversion that would result in a string with more digits than the limit will raise a ValueError. However, for certain large numbers, this check does not seem to occur, and the conversion succeeds without error. I tested this with the maximum number of digits set to 100,000. This allowed numbers with up to 100424 digits but threw an error for numbers with 100425 or more digits.
This doesn't seem to be an issue for all possible inputs to the sys.set_int_max_str_digits() method. For instance, I also tested it with the maximum number of digits set to 640. It correctly threw an error when I tried to do str(10**640).

Steps to Reproduce

10**100423 has 100424 digits, therefore str(10**100423) should throw a ValueError but it does not. Instead, the code below prints 100424.

import sys

sys.set_int_max_str_digits(100000)

number_str = str(10**100423)
print(len(number_str))

CPython versions tested on:

3.12

Operating systems tested on:

Windows

Linked PRs

• gh-136250: Clarify Integer string conversion length limitation #136279

[skirpichev]

appears to not enforce the configured limit when converting a very large integer to a string

That contradicts to:

I tested this with the maximum number of digits set to 100,000. This allowed numbers with up to 100424 digits but threw an error for numbers with 100425 or more digits.

So - limit is actually enforced.

I suspect your confusion is that error is not raised for exact limit you set. But we just don't know exactly how long will be the output string. Such exact estimation will be very costly.

It's not a bug, but maybe a minor documentation issue.

[skirpichev]

See

cpython/Objects/longobject.c

Lines 2066 to 2081 in da79ac9

	/* quick and dirty pre-check for overflowing the decimal digit limit,
	based on the inequality 10/3 >= log2(10)
	explanation in https://github.com/python/cpython/pull/96537
	*/
	if (size_a >= 10 * _PY_LONG_MAX_STR_DIGITS_THRESHOLD
	/ (3 * PyLong_SHIFT) + 2) {
	PyInterpreterState *interp = _PyInterpreterState_GET();
	int max_str_digits = interp->long_state.max_str_digits;
	if ((max_str_digits > 0) &&
	(max_str_digits / (3 * PyLong_SHIFT) <= (size_a - 11) / 10)) {
	PyErr_Format(PyExc_ValueError, _MAX_STR_DIGITS_ERROR_FMT_TO_STR,
	max_str_digits);
	return -1;
	}
	}

[bell-bot]

Got it, that makes sense. Thanks!

[KentaroJay]

@skirpichev
I can make a slight improvement on the documentation. Probably around here

Adding the limitation of the estimation would help the reader. What do you think?

[terryjreedy]

Yes, please mention that the limit applies to an estimate of the size, as the purpose of the limit is to not actually convert to a string. 425/100000 is .00425, less than 1%.

[skirpichev]

Probably around here

Please try. The problem is not the exact place, but actual wording.

Adding the limitation of the estimation would help the reader.

Perhaps, but this doesn't look too severe for me. People either want bigints or not. If they want - limitations coming from the sys.set_int_max_str_digits() are just ridiculous. If not - default limitations should be fine for them.

I think that this could be more easily documented, if we estimate the upper bound of the string size and add a constraint on this value. This should be doable. BTW, the GMP's mpn_sizeinbase() is off just by one digit (or exact), but we don't need such precision.

[KentaroJay]

@terryjreedy @skirpichev
I opened the PR regarding this. I tried to incorporate your opinions in the fix. Point me out if I am misunderstanding your thoughts (if you want to review 👍 )