(FOO 1.5)
will cause the INTEGERP case to be selected, giving bogus output a la
exactly 2.5
- (or (FOO 1000.5), "exactly 1001.5")
This violates the "declarations are assertions" principle.
According to the ANSI spec, in the section "System Class FUNCTION",
this is a case of "lying to the compiler", but the lying is done
type safety errors reported by Peter Van Eynde July 25, 2000:
c: (COERCE 'AND 'FUNCTION) returns something related to
(MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
- h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
- should signal TYPE-ERROR.
- i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
- be used for input and output as needed. It should fail with
- TYPE-ERROR when handed e.g. the results of
- MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
- the inappropriate positions, but doesn't.
k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
not a binary input stream, but instead cheerfully reads from
character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
causes a COMPILER-ERROR.
-48:
- SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
- c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
- it binds is declared SPECIAL inside.
-
51:
miscellaneous errors reported by Peter Van Eynde July 25, 2000:
a: (PROGN
(I haven't tried to investigate this bug enough to guess whether
there might be any user-level symptoms.)
+ In fact, the type system is likely to depend on this inequality not
+ holding... * is not equivalent to T in many cases, such as
+ (VECTOR *) /= (VECTOR T).
+
94a:
Inconsistencies between derived and declared VALUES return types for
DEFUN aren't checked very well. E.g. the logic which successfully
time trying to GC afterwards. Surely there's some more economical
way to implement (ROOM T).
-110:
- reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
- collection:
- ;;; The compiler is flushing the argument type test, and the default
- ;;; case in the cond, so that calling with say a fixnum 0 causes a
- ;;; SIGBUS.
- (declaim (optimize (safety 2) (speed 3)))
- (defun tst (x)
- (declare (type (or string stream) x))
- (cond ((typep x 'string) 'string)
- ((typep x 'stream) 'stream)
- (t
- 'none)))
- The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
- (not the SIGBUS reported in the comment) but that's broken too;
- type declarations are supposed to be treated as assertions unless
- SAFETY 0, so we should be getting a TYPE-ERROR.
-
115:
reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
collection:
124:
As of version 0.pre7.14, SBCL's implementation of MACROLET makes
the entire lexical environment at the point of MACROLET available
- in the bodies of the macroexpander functions. In particular, it
- allows the function bodies (which run at compile time) to try to
+ in the bodies of the macroexpander functions. In particular, it
+ allows the function bodies (which run at compile time) to try to
access lexical variables (which are only defined at runtime).
It doesn't even issue a warning, which is bad.
-
+
The SBCL behavior arguably conforms to the ANSI spec (since the
spec says that the behavior is undefined, ergo anything conforms).
However, it would be better to issue a compile-time error.
the local macro definitions in a MACROLET, but the consequences
are undefined if the local macro definitions reference any
local variable or function bindings that are visible in that
- lexical environment.
+ lexical environment.
Then it seems to contradict itself by giving the example
(defun foo (x flag)
(macrolet ((fudge (z)
but actual specification quoted above says that the actual behavior
is undefined.
+ (Since 0.7.8.23 macroexpanders are defined in a restricted version
+ of the lexical environment, containing no lexical variables and
+ functions, which seems to conform to ANSI and CLtL2, but signalling
+ a STYLE-WARNING for references to variables similar to locals might
+ be a good thing.)
+
125:
(as reported by Gabe Garza on cmucl-help 2001-09-21)
(defvar *tmp* 3)
structure classes related by inheritance. As of 0.7.0, SBCL still
doesn't follow it.
-129:
- insufficient syntax checking in MACROLET:
- (defun foo (x)
- (macrolet ((defmacro bar (z) `(+ z z)))
- (bar x)))
- shouldn't compile without error (because of the extra DEFMACRO symbol).
-
135:
Ideally, uninterning a symbol would allow it, and its associated
- FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
+ FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
at least as of sbcl-0.7.0, this isn't the case. Information about
FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
essentially in ordinary (non-weak) hash tables keyed by symbols.
Thus, once a system has an entry in this system, it tends to live
forever, even when it is uninterned and all other references to it
- are lost.
+ are lost.
136:
(reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
T
* (defclass b () ())
#<STANDARD-CLASS B>
-
+
;;; And now...
* (subtypep 'b 'a)
T
This bug was fixed in sbcl-0.7.4.1 by invalidating the PCL wrapper
class upon redefinition. Unfortunately, doing so causes bug #176 to
- appear. Pending further investication, one or other of these bugs
+ appear. Pending further investigation, one or other of these bugs
might be present at any given time.
141:
* (lisp-implementation-version)
"0.pre7.129"
-142:
- (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16)
- %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte
- of the naturalized string. We could probably port the patches
- from the cmucl-imp mailing list.
-
143:
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
prominent SourceForge web/db bug tracking system, which is
debugger invoked on condition of type TYPE-ERROR:
The value NIL is not of type SB-C::NODE.
The location of this failure has moved around as various related
- issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
+ issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
-153:
- (essentially the same problem as a CMU CL bug reported by Martin
- Cracauer on cmucl-imp 2002-02-19)
- There is a hole in structure slot type checking. Compiling and LOADing
- (declaim (optimize safety))
- (defstruct foo
- (bla 0 :type fixnum))
- (defun f ()
- (let ((foo (make-foo)))
- (setf (foo-bla foo) '(1 . 1))
- (format t "Is ~a of type ~a a cons? => ~a~%"
- (foo-bla foo)
- (type-of (foo-bla foo))
- (consp (foo-bla foo)))))
- (f)
- should signal an error, but in sbcl-0.7.1.21 instead gives the output
- Is (1 . 1) of type CONS a cons? => NIL
- without signalling an error.
+ (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
+ expand KID-FROB into %ZEEP. Having partially done it, it sees a call
+ of KIDIFY1, which already does not exist. So it gives up on
+ expansion, leaving garbage consisting of infinished blocks of the
+ partially converted function.)
157:
Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
In sbcl-0.7.4.24, compiling
(defun bug178 (x)
(funcall (the function (the standard-object x))))
- gives
+ gives
failed AVER:
"(AND (EQ (IR2-CONTINUATION-PRIMITIVE-TYPE 2CONT) FUNCTION-PTYPE) (EQ CHECK T))"
This variant compiles OK, though:
(defun bug178alternative (x)
(funcall (the nil x)))
+ (since 0.7.8.9 it does not signal an error; see also bug 199)
+
183: "IEEE floating point issues"
Even where floating point handling is being dealt with relatively
well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
(print j))))
(trust-assertion 6) ; prints nothing unless DECLARE is commented out
+ (see bug 203)
+
193: "unhelpful CLOS error reporting when the primary method is missing"
In sbcl-0.7.7, when
(defmethod foo :before ((x t)) (print x))
APD further reports that this bug is not present in CMUCL.
+ (this case was fixed in 0.7.8.9; see also bug 178)
+
201: "Incautious type inference from compound CONS types"
(reported by APD sbcl-devel 2002-09-17)
(DEFUN FOO (X)
(FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
+203:
+ Compiler does not check THEs on unused values, e.g. in
+
+ (progn (the real (list 1)) t)
+
+ This situation may appear during optimizing away degenerate cases of
+ certain functions: see bugs 54, 192b.
+
+205: "environment issues in cross compiler"
+ (These bugs have no impact on user code, but should be fixed or
+ documented.)
+ a. Macroexpanders introduced with MACROLET are defined in the null
+ lexical environment.
+ b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
+ the null lexical environment.
+
+206: ":SB-FLUID feature broken"
+ (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
+ Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
+ the build.
+
+207: "poorly distributed SXHASH results for compound data"
+ SBCL's SXHASH could probably try a little harder. ANSI: "the
+ intent is that an implementation should make a good-faith
+ effort to produce hash-codes that are well distributed
+ within the range of non-negative fixnums". But
+ (let ((hits (make-hash-table)))
+ (dotimes (i 16)
+ (dotimes (j 16)
+ (let* ((ij (cons i j))
+ (newlist (push ij (gethash (sxhash ij) hits))))
+ (when (cdr newlist)
+ (format t "~&collision: ~S~%" newlist))))))
+ reports lots of collisions in sbcl-0.7.8. A stronger MIX function
+ would be an obvious way of fix. Maybe it would be acceptably efficient
+ to redo MIX using a lookup into a 256-entry s-box containing
+ 29-bit pseudorandom numbers?
+
+208: "package confusion in PCL handling of structure slot handlers"
+ In sbcl-0.7.8 compiling and loading
+ (in-package :cl)
+ (defstruct foo (slot (error "missing")) :type list :read-only t)
+ (defmethod print-object ((foo foo) stream) (print nil stream))
+ causes CERROR "attempting to modify a symbol in the COMMON-LISP
+ package: FOO-SLOT". (This is fairly bad code, but still it's hard
+ to see that it should cause symbols to be interned in the CL package.)
+
+209: "DOCUMENTATION generic function has wrong argument precedence order"
+ The method from
+ (DEFMETHOD DOCUMENTATION ((X (EQL '+)) Y) "WRONG!")
+ should not be executed in the call
+ (DOCUMENTATION '+ 'FUNCTION),
+ as the DOCUMENTATION generic function has a different argument
+ precedence order (see its entry in the CLHS). However, despite a
+ correct generic function definition in the PCL source code, SBCL
+ returns "WRONG!" for the call.
+
+210: "unsafe evaluation of DEFSTRUCT slot initforms in BOA constructors"
+ (fixed in sbcl-0.7.8.35)
+
DEFUNCT CATEGORIES OF BUGS
IR1-#:
These labels were used for bugs related to the old IR1 interpreter.
projects / sbcl.git / blobdiff