iSharkFly-Open
/
python-peps
mirror of https://github.com/python/peps.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

PEP 651 rejected by the SC (#1864)

This commit is contained in:
Victor Stinner 2021-03-09 15:03:20 +01:00 committed by GitHub
parent 9caeab3687
commit c91e284b01
No known key found for this signature in database
GPG Key ID: 4AEE18F83AFDEB23
1 changed files with 14 additions and 7 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
pep-0651.rst
View File

@ -1,13 +1,20 @@
PEP: 651 PEP: 651
Title: Robust Stack Overflow Handling Title: Robust Stack Overflow Handling
Author: Mark Shannon <mark@hotpy.org> Author: Mark Shannon <mark@hotpy.org>
Status: Draft Status: Rejected
Type: Standards Track Type: Standards Track
Content-Type: text/x-rst Content-Type: text/x-rst
Created: 18-Jan-2021 Created: 18-Jan-2021
Post-History: 19-Jan-2021 Post-History: 19-Jan-2021
Rejection Notice
================
This PEP has been `rejected by the Python Steering Council
<https://mail.python.org/archives/list/python-dev@python.org/thread/75BFSBM5AJWXOF5OSPLMJQSTP3TDOKRP/>`_.
Abstract Abstract
======== ========
@ -41,7 +48,7 @@ Motivation
CPython uses a single recursion depth counter to prevent both runaway recursion and C stack overflow. CPython uses a single recursion depth counter to prevent both runaway recursion and C stack overflow.
However, runaway recursion and machine stack overflow are two different things. However, runaway recursion and machine stack overflow are two different things.
Allowing machine stack overflow is a potential security vulnerability, but limiting recursion depth can prevent the Allowing machine stack overflow is a potential security vulnerability, but limiting recursion depth can prevent the
use of some algorithms in Python. use of some algorithms in Python.
Currently, if a program needs to deeply recurse it must manage the maximum recursion depth allowed, Currently, if a program needs to deeply recurse it must manage the maximum recursion depth allowed,
@ -89,7 +96,7 @@ so any code that handles ``RecursionError`` will continue to work as before.
Decoupling the Python stack from the C stack Decoupling the Python stack from the C stack
-------------------------------------------- --------------------------------------------
In order to provide the above guarantees and ensure that any program that worked previously In order to provide the above guarantees and ensure that any program that worked previously
continues to do so, the Python and C stack will need to be separated. continues to do so, the Python and C stack will need to be separated.
That is, calls to Python functions from Python functions, should not consume space on the C stack. That is, calls to Python functions from Python functions, should not consume space on the C stack.
Calls to and from builtin functions will continue to consume space on the C stack. Calls to and from builtin functions will continue to consume space on the C stack.
@ -109,7 +116,7 @@ Other Implementations
Other implementations are required to fail safely regardless of what value the recursion limit is set to. Other implementations are required to fail safely regardless of what value the recursion limit is set to.
If the implementation couples the Python stack to the underlying VM or hardware stack, If the implementation couples the Python stack to the underlying VM or hardware stack,
then it should raise a ``RecursionOverflow`` exception when the recursion limit is exceeded, then it should raise a ``RecursionOverflow`` exception when the recursion limit is exceeded,
but the underlying stack does not overflow. but the underlying stack does not overflow.
If the underlying stack overflows, or is near to overflow, If the underlying stack overflows, or is near to overflow,
then a ``StackOverflow`` exception should be raised. then a ``StackOverflow`` exception should be raised.
@ -146,7 +153,7 @@ Some low-level tools, such as machine-code debuggers, will need to be modified.
For example, the gdb scripts for Python will need to be aware that there may be more than one Python frame For example, the gdb scripts for Python will need to be aware that there may be more than one Python frame
per C frame. per C frame.
C code that uses the ``Py_EnterRecursiveCall()``, ``PyLeaveRecursiveCall()`` pair of C code that uses the ``Py_EnterRecursiveCall()``, ``PyLeaveRecursiveCall()`` pair of
functions will continue to work correctly. In addition, ``Py_EnterRecursiveCall()`` functions will continue to work correctly. In addition, ``Py_EnterRecursiveCall()``
may raise a ``StackOverflow`` exception. may raise a ``StackOverflow`` exception.
@ -185,9 +192,9 @@ We need to determine a safe bounds for the stack, which is not something possibl
For major platforms, the platform specific API will be used to provide an accurate stack bounds. For major platforms, the platform specific API will be used to provide an accurate stack bounds.
However, for minor platforms some amount of guessing may be required. However, for minor platforms some amount of guessing may be required.
While this might sound bad, it is no worse than the current situation, where we guess that the While this might sound bad, it is no worse than the current situation, where we guess that the
size of the C stack is at least 1000 times the stack space required for the chain of calls from size of the C stack is at least 1000 times the stack space required for the chain of calls from
``_PyEval_EvalFrameDefault`` to ``_PyEval_EvalFrameDefault``. ``_PyEval_EvalFrameDefault`` to ``_PyEval_EvalFrameDefault``.
This means that in some cases the amount of recursion possible may be reduced. This means that in some cases the amount of recursion possible may be reduced.
In general, however, the amount of recursion possible should be increased, as many calls will use no C stack. In general, however, the amount of recursion possible should be increased, as many calls will use no C stack.