+ or a more simple example:
+
+ (locally
+ (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
+ (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x))))
+
+215: ":TEST-NOT handling by functions"
+ a. FIND and POSITION currently signal errors when given non-NIL for
+ both their :TEST and (deprecated) :TEST-NOT arguments, but by
+ ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
+ means that the effect is "unpredictable but harmless. It's not
+ clear what that actually means; it may preclude conforming
+ implementations from signalling errors.
+ b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
+ when conflict occurs. As a quality of implementation issue, it
+ might be preferable to treat :TEST and :TEST-NOT as being in some
+ sense the same &KEY, and effectively take the first test function in
+ the argument list.
+ c. Again, a quality of implementation issue: it would be good to issue a
+ STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
+ WARNING for calls with both :TEST and :TEST-NOT; possibly this
+ latter should be WARNed about at execute-time too.
+
+216: "debugger confused by frames with invalid number of arguments"
+ In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
+ leaves the system confused, enough so that (QUIT) no longer works.
+ It's as though the process of working with the uninitialized slot in
+ the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
+ not be the actual problem. (CMU CL 18c doesn't have problems with this.)
+
+217: "Bad type operations with FUNCTION types"
+ In sbcl.0.7.7:
+
+ * (values-type-union (specifier-type '(function (base-char)))
+ (specifier-type '(function (integer))))
+
+ #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
+
+ It causes insertion of wrong type assertions into generated
+ code. E.g.
+
+ (defun foo (x s)
+ (let ((f (etypecase x
+ (character #'write-char)
+ (integer #'write-byte))))
+ (funcall f x s)
+ (etypecase x
+ (character (write-char x s))
+ (integer (write-byte x s)))))
+
+ Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
+
+ (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
+ produce invalid code, but type checking is not accurate. Similar
+ problems exist with VALUES-TYPE-INTERSECTION.)
+
+218: "VALUES type specifier semantics"
+ (THE (VALUES ...) ...) in safe code discards extra values.
+
+ (defun test (x y) (the (values integer) (truncate x y)))
+ (test 10 4) => 2
+
+219: "DEFINE-COMPILER-MACRO in non-toplevel contexts evaluated at compile-time"
+ In sbcl-0.7.9:
+
+ * (defun foo (x)
+ (when x
+ (define-compiler-macro bar (&whole whole)
+ (declare (ignore whole))
+ (print "expanding compiler macro")
+ 1)))
+ FOO
+ * (defun baz (x) (bar))
+ [ ... ]
+ "expanding compiler macro"
+ BAZ
+ * (baz t)
+ 1
+