(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
46:
type safety errors reported by Peter Van Eynde July 25, 2000:
- a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
- => #(A B C)
- In general lengths of array type specifications aren't
- checked by COERCE, so it fails when the spec is
- (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
- b: CONCATENATE has the same problem of not checking the length
- of specified output array types. MAKE-SEQUENCE and MAP and
- MERGE also have the same problem.
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))
the new output block should start indented 2 or more characters
rightward of the correct location.
-66:
- ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
- a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
- (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
- This also leads to funny behavior when derived type specifiers
- are used, as originally reported by Milan Zamazal for CMU CL (on the
- Debian bugs mailing list (?) 2000-02-27), then reported by Martin
- Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
- (DEFTYPE FOO () 'SIMPLE-ARRAY)
- (CONCATENATE 'FOO #(1 2) '(3))
- => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
- sequence functions.
- The derived type specifier FOO should act the same way as the
- built-in type SIMPLE-ARRAY here, but it doesn't. That problem
- doesn't seem to exist for sequence types:
- (DEFTYPE BAR () 'SIMPLE-VECTOR)
- (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
- See also bug #46a./b., and discussion and patch sbcl-devel and
- cmucl-imp 2002-07
-
67:
As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
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:
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
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.
-
157:
Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and
UPGRADED-COMPLEX-PART-TYPE should have an optional environment argument.
(FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
-202:
- In 0.6.12.43 compilation of a function definition, contradicting its
- FTYPE proclamation, causes an error, e.g. COMPILE-FILE on
-
- (declaim (ftype (function () null) foo))
- (defun foo () t)
-
- fails with
-
- debugger invoked on condition of type UNBOUND-VARIABLE:
- The variable SB-C::*ERROR-FUNCTION* is unbound.
-
- in
+203:
+ Compiler does not check THEs on unused values, e.g. in
- (SB-C::NOTE-LOSSAGE
- "~@<The previously declared FTYPE~2I ~_~S~I ~_~
- conflicts with the definition type ~2I~_~S~:>"
- (FUNCTION NIL NULL)
- (FUNCTION NIL #))
+ (progn (the real (list 1)) t)
- (In 0.7.0 the variable was renamed to SB-C::*LOSSAGE-FUN*.)
+ This situation may appear during optimizing away degenerate cases of
+ certain functions: see bugs 54, 192b.
DEFUNCT CATEGORIES OF BUGS
IR1-#:
projects / sbcl.git / blobdiff