From b62efad943443c89d8bd7d33715393984b04c0e0 Mon Sep 17 00:00:00 2001 From: Armin Rigo Date: Tue, 25 Jul 2006 18:38:39 +0000 Subject: Document the crashers that will not go away soon as "won't fix", and explain why. --- Lib/test/crashers/bogus_code_obj.py | 10 ++++++++++ Lib/test/crashers/recursive_call.py | 5 +++++ 2 files changed, 15 insertions(+) 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) -- cgit v0.12