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)
(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-#: