diff options
| -rw-r--r-- | Lib/test/crashers/bogus_code_obj.py | 10 | ||||
| -rw-r--r-- | Lib/test/crashers/recursive_call.py | 5 |
2 files changed, 15 insertions, 0 deletions
diff --git a/Lib/test/crashers/bogus_code_obj.py b/Lib/test/crashers/bogus_code_obj.py index 5438d91..613ae51 100644 --- a/Lib/test/crashers/bogus_code_obj.py +++ b/Lib/test/crashers/bogus_code_obj.py @@ -1,5 +1,15 @@ """ Broken bytecode objects can easily crash the interpreter. + +This is not going to be fixed. It is generally agreed that there is no +point in writing a bytecode verifier and putting it in CPython just for +this. Moreover, a verifier is bound to accept only a subset of all safe +bytecodes, so it could lead to unnecessary breakage. + +For security purposes, "restricted" interpreters are not going to let +the user build or load random bytecodes anyway. Otherwise, this is a +"won't fix" case. + """ import types diff --git a/Lib/test/crashers/recursive_call.py b/Lib/test/crashers/recursive_call.py index 0776479..31c8963 100644 --- a/Lib/test/crashers/recursive_call.py +++ b/Lib/test/crashers/recursive_call.py @@ -1,6 +1,11 @@ #!/usr/bin/env python # No bug report AFAIK, mail on python-dev on 2006-01-10 + +# This is a "won't fix" case. It is known that setting a high enough +# recursion limit crashes by overflowing the stack. Unless this is +# redesigned somehow, it won't go away. + import sys sys.setrecursionlimit(1 << 30) |