-
-
Notifications
You must be signed in to change notification settings - Fork 23
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Is it OK to implement stack protection? #102
Comments
I've added it as the 19th item on our agenda. 😅 |
Thanks. |
The SC is fine with adding stack protection and raising an exception instead of crashing, as long as the mechanisms are either portable or conditional on platform support. However, the exception should be |
I believe that python/cpython#96510 has not completely implemented the resolution by SC, e.g. no See also python/cpython#112282 and python/cpython#112215 pointing at related issues that this has caused. |
python/cpython#91079 (comment) explains why the exception must be a subclass of |
C stack overflow has lately been a problem for building and testing CPython, and it is a concern that it may impact users as well.
The root cause is that compilers, especially Clang use a lot more C stack for debug builds, meaning that at the full default recursion limit of 1000, C stack overflows are likely.
I would like to fix CPython to raise an exception (for major platforms at least) instead of faulting. We already do this partially for Windows.
PEP 651 proposed doing this, but was rejected. I don't want to appear to be implementing PEP 651 by stealth, so I wanted the SC's approval first.
PEP 651 included the following:
I plan to implement the above check, but without adding a new Exception type, raising a RecursionError as happens when the recursion limit is reached.
The text was updated successfully, but these errors were encountered: