sys.setrecursionlimit: OverflowError still raised when int limited in sys.maxsize

[wyz23x2]

BPO	41313
Nosy	@mdickinson, @skrah, @wyz23x2

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2020-07-16.21:58:52.982>
created_at = <Date 2020-07-16.07:47:19.214>
labels = ['type-bug', '3.8', '3.9', '3.10', 'expert-C-API', 'library', 'invalid']
title = 'sys.setrecursionlimit: OverflowError still raised when int limited in sys.maxsize'
updated_at = <Date 2020-07-16.21:58:52.981>
user = 'https://github.com/wyz23x2'

bugs.python.org fields:

activity = <Date 2020-07-16.21:58:52.981>
actor = 'skrah'
assignee = 'none'
closed = True
closed_date = <Date 2020-07-16.21:58:52.982>
closer = 'skrah'
components = ['Library (Lib)', 'C API']
creation = <Date 2020-07-16.07:47:19.214>
creator = 'wyz23x2'
dependencies = []
files = []
hgrepos = []
issue_num = 41313
keywords = []
message_count = 6.0
messages = ['373747', '373748', '373749', '373751', '373761', '373774']
nosy_count = 3.0
nosy_names = ['mark.dickinson', 'skrah', 'wyz23x2']
pr_nums = []
priority = 'normal'
resolution = 'not a bug'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue41313'
versions = ['Python 3.8', 'Python 3.9', 'Python 3.10']

[wyz23x2]

Consider this code:
import sys
sys.setrecursionlimit(sys.maxsize)
Causes this:
OverflowError: Python int too large to convert to C int
So what is the limit? It should be sys.maxsize.
These 2 also don't work:
sys.setrecursionlimit(sys.maxsize-1)
sys.setrecursionlimit(sys.maxsize//2)
That is a big difference with at least 50%.

[wyz23x2]

Needs to add 10 zeros (sys.maxsize//10000000000) to get it work. //20000000000 doesn't work.
Python version: 3.8.4
Platform: Windows 10 2004

[wyz23x2]

Tested. 2**31-31 is the max, which is 2147483617, compared to sys.maxsize's 9223372036854775807!

[mdickinson]

The recursion depth and recursion limit are stored internally as C ints, so yes, 2**31 - 1 = 2147483647 is the maximum value that you can pass to sys.setrecursionlimit that won't fail immediately.

But it's unclear why you'd ever want to set the recursion limit that high. What's your goal here? Are you looking for a way to effectively disable that recursion limit altogether? If so, can you explain the use-case?

Note that the recursion limit is there to prevent your code from exhausting the C stack and segfaulting as a result: simply setting that limit to a huge value won't (by itself) allow you to run arbitrarily deeply nested recursions. On my machine, without the protection of the recursion limit, a simple recursive call segfaults at around a depth of 30800.

[mdickinson]

Setting to pending; I don't see any bug here, and I suspect the original report was based on a misunderstanding of what sys.setrecursionlimit is for.

[skrah]

Mark has already mentioned that setting the recursion limit to a
value higher than 2000-10000 makes no sense.

Apart from that, sys.maxsize is actually documented like this:

maxsize -- the largest supported length of containers.

So it applies to Py_ssize_t (signed version of size_t), but not to
any C integer in general.