Lengthy numbers

Oscar Benjamin oscar.j.benjamin at gmail.com
Sun Dec 22 18:32:30 EST 2024


On Sun, 22 Dec 2024 at 19:17, Gilmeh Serda via Python-list
<python-list at python.org> wrote:
>
> Was just playing with numbers and stumbled on something I've never seen
> before.
...
>
> >>> 9**9**4
> Traceback (most recent call last):
>   File "<stdin>", line 1, in <module>
> ValueError: Exceeds the limit (4300 digits) for integer string conversion;
> use sys.set_int_max_str_digits() to increase the limit
>
> Explanation:
> https://discuss.python.org/t/int-str-conversions-broken-in-latest-python-bugfix-releases/18889

I think that the original security concern was mainly motivated by the
string to int direction i.e. calling int(s) for a possibly large
string s (possibly from an untrusted source) might be slow with
CPython. To solve that problem conversions from string->int and
int->string were disallowed. Now that more time has passed it becomes
clearer that disabling int->string conversion is more likely to be the
thing that people bump into as a result of this limitation (as you
just did). I find it harder to see what the security problem is in
that direction but I don't think this will be changed.

CPython has an implementation of arbitrarily large integers but an
important part of it is hobbled. If you do want to work with such
large integers then I recommend using either gmpy2's gmpy2.mpz type or
python-flint's flint.fmpz type.

At the same time it is not hard to run into slowness with integers
e.g. 10**10**10 but that won't come up in string parsing if not using
eval. Not a likely security issue but I am suddenly reminded of this
dangerous snippet:

  x = [0]; x.extend(iter(x))

If you want to test it then make sure to save your work etc and be
prepared to hard reset the computer. On this machine Ctrl-C doesn't
work for this but Ctrl-\ does if you do it quick enough.

--
Oscar


More information about the Python-list mailing list