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

and explain why.

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 5438d912b1..613ae518d4 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 077647995f..31c8963303 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)