Document the crashers that will not go away soon as "won't fix",

and explain why.

diff --git a/Lib/test/crashers/bogus_code_obj.py b/Lib/test/crashers/bogus_code_obj.py
index 5438d912b157f767304e91ce293318d1df50269e..613ae518d4efe5498933c8e37f32c75abb7bb827 100644 (file)
--- 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 077647995f12a20a8fb7efc66f228f9f5842ea6e..31c89633032a651fa936c69d1aa4ed23bb77ec96 100644 (file)
--- 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)