3 Bugs can be reported on the help mailing list
4 sbcl-help@lists.sourceforge.net
5 or on the development mailing list
6 sbcl-devel@lists.sourceforge.net
8 Please include enough information in a bug report that someone reading
9 it can reproduce the problem, i.e. don't write
10 Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
11 PRINT-OBJECT doesn't seem to work with *PRINT-LENGTH*. Is this a bug?
13 Subject: apparent bug in PRINT-OBJECT (or *PRINT-LENGTH*?)
14 In sbcl-1.2.3 running under OpenBSD 4.5 on my Alpha box, when
15 I compile and load the file
16 (DEFSTRUCT (FOO (:PRINT-OBJECT (LAMBDA (X Y)
17 (LET ((*PRINT-LENGTH* 4))
20 then at the command line type
22 the program loops endlessly instead of printing the object.
27 There is also some information on bugs in the manual page and
28 in the TODO file. Eventually more such information may move here.
30 The gaps in the number sequence belong to old bug descriptions which
31 have gone away (typically because they were fixed, but sometimes for
32 other reasons, e.g. because they were moved elsewhere).
35 KNOWN BUGS OF NO SPECIAL CLASS:
38 DEFSTRUCT almost certainly should overwrite the old LAYOUT information
39 instead of just punting when a contradictory structure definition
40 is loaded. As it is, if you redefine DEFSTRUCTs in a way which
41 changes their layout, you probably have to rebuild your entire
42 program, even if you know or guess enough about the internals of
43 SBCL to wager that this (undefined in ANSI) operation would be safe.
46 ANSI specifies that a type mismatch in a structure slot
47 initialization value should not cause a warning.
49 This one might not be fixed for a while because while we're big
50 believers in ANSI compatibility and all, (1) there's no obvious
51 simple way to do it (short of disabling all warnings for type
52 mismatches everywhere), and (2) there's a good portable
53 workaround. ANSI justifies this specification by saying
54 The restriction against issuing a warning for type mismatches
55 between a slot-initform and the corresponding slot's :TYPE
56 option is necessary because a slot-initform must be specified
57 in order to specify slot options; in some cases, no suitable
59 In SBCL, as in CMU CL (or, for that matter, any compiler which
60 really understands Common Lisp types) a suitable default does
61 exist, in all cases, because the compiler understands the concept
62 of functions which never return (i.e. has return type NIL, e.g.
63 ERROR). Thus, as a portable workaround, you can use a call to
64 some known-never-to-return function as the default. E.g.
66 (BAR (ERROR "missing :BAR argument")
67 :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
69 (DECLAIM (FTYPE () NIL) MISSING-ARG)
70 (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
71 (ERROR "missing required argument"))
73 (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
74 (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
75 (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
76 Such code will compile without complaint and work correctly either
77 on SBCL or on a completely compliant Common Lisp system.
80 bogus warnings about undefined functions for magic functions like
81 SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
82 like src/code/float.lisp. Fixing this will probably require
83 straightening out enough bootstrap consistency issues that
84 the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
85 Instead, the cross-compiler runs in a slightly flaky state
86 which is sane enough to compile SBCL itself, but which is
87 also unstable in several ways, including its inability
88 to really grok function declarations.
91 The "byte compiling top-level form:" output ought to be condensed.
92 Perhaps any number of such consecutive lines ought to turn into a
93 single "byte compiling top-level forms:" line.
96 The way that the compiler munges types with arguments together
97 with types with no arguments (in e.g. TYPE-EXPAND) leads to
98 weirdness visible to the user:
99 (DEFTYPE FOO () 'FIXNUM)
101 (TYPEP 11 '(FOO)) => T, which seems weird
102 (TYPEP 11 'FIXNUM) => T
103 (TYPEP 11 '(FIXNUM)) signals an error, as it should
104 The situation is complicated by the presence of Common Lisp types
105 like UNSIGNED-BYTE (which can either be used in list form or alone)
106 so I'm not 100% sure that the behavior above is actually illegal.
107 But I'm 90+% sure, and the following related behavior,
109 treating the bare symbol AND as equivalent to '(AND), is specifically
110 forbidden (by the ANSI specification of the AND type).
113 It would be nice if the
115 (during macroexpansion)
116 said what macroexpansion was at fault, e.g.
118 (during macroexpansion of IN-PACKAGE,
119 during macroexpansion of DEFFOO)
122 (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
123 '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
124 (Also, when this is fixed, we can enable the code in PROCLAIM which
125 checks for incompatible FTYPE redeclarations.)
128 from DTC on the CMU CL mailing list 25 Feb 2000:
129 ;;; Compiler fails when this file is compiled.
131 ;;; Problem shows up in delete-block within ir1util.lisp. The assertion
132 ;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
133 ;;; fails within bind node branch.
135 ;;; Note that if c::*check-consistency* is enabled then an un-reached
136 ;;; entry is also reported.
139 (declare (values nil))
156 (let ((ttt #'(lambda () (go cccc))))
157 (declare (special ttt))
158 (return-from bbbb nil))
161 (return-from bbbb nil))))))
164 (I *think* this is a bug. It certainly seems like strange behavior. But
165 the ANSI spec is scary, dark, and deep..)
166 (FORMAT NIL "~,1G" 1.4) => "1. "
167 (FORMAT NIL "~3,1G" 1.4) => "1. "
170 from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
172 (setf (find-class 'ccc1) (find-class 'ccc))
173 (defmethod zut ((c ccc1)) 123)
174 DTC's recommended workaround from the mailing list 3 Mar 2000:
175 (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
178 The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
179 says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
180 inside "~<..~>" (without the colon modifier on the closing syntax).
181 However, SBCL doesn't do this:
182 * (FORMAT T "~<munge~wegnum~>" 12)
187 Sometimes (SB-EXT:QUIT) fails with
188 Argh! maximum interrupt nesting depth (4096) exceeded, exiting
189 Process inferior-lisp exited abnormally with code 1
190 I haven't noticed a repeatable case of this yet.
193 some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
196 (BLOCK USED-BY-SOME-Y?
199 (UNLESS (REJECTED? Y)
200 (RETURN-FROM USED-BY-SOME-Y? T)))))
201 (DECLARE (INLINE FROB))
206 error in function SB-KERNEL:ASSERT-ERROR:
207 The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
208 This is still present in sbcl-0.6.8.
211 In some cases the compiler believes type declarations on array
212 elements without checking them, e.g.
213 (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1)))
216 (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X))
217 (WHEN (CONSP (AREF X 0))
219 (BAR (VECTOR (MAKE-FOO :A 11 :B 12)))
222 in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for
223 all cases, e.g. the type assumption *is* checked if the array
224 elements are declared to be of some structure type instead of CONS.
227 The printer doesn't report closures very well. This is true in
231 #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
232 It would be nice to make closures have a settable name slot,
233 and make things like DEFSTRUCT and FLET, which create closures,
234 set helpful values into this slot.
237 And as long as we're wishing, it would be awfully nice if INSPECT could
238 also report on closures, telling about the values of the bound variables.
241 The compiler assumes that any time a function of declared FTYPE
242 doesn't signal an error, its arguments were of the declared type.
243 E.g. compiling and loading
244 (DECLAIM (OPTIMIZE (SAFETY 3)))
245 (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
246 (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL)))
248 (COND ((> (FACTORIAL X) 1.0E6)
249 (FORMAT T "too big~%"))
251 (FORMAT T "exactly ~S~%" (FACTORIAL X)))
253 (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
256 will cause the INTEGERP case to be selected, giving bogus output a la
258 This violates the "declarations are assertions" principle.
259 According to the ANSI spec, in the section "System Class FUNCTION",
260 this is a case of "lying to the compiler", but the lying is done
261 by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
262 not by the unexpectedly general definition of FACTORIAL. In any case,
263 "declarations are assertions" means that lying to the compiler should
264 cause an error to be signalled, and should not cause a bogus
265 result to be returned. Thus, the compiler should not assume
266 that arbitrary functions check their argument types. (It might
267 make sense to add another flag (CHECKED?) to DEFKNOWN to
268 identify functions which *do* check their argument types.)
269 (Also, verify that the compiler handles declared function
270 return types as assertions.)
273 DEFMETHOD doesn't check the syntax of &REST argument lists properly,
274 accepting &REST even when it's not followed by an argument name:
275 (DEFMETHOD FOO ((X T) &REST) NIL)
278 TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in
279 (DEFTYPE INDEXOID () '(INTEGER 0 1000))
281 (DECLARE (TYPE INDEXOID X))
282 (THE (VALUES INDEXOID)
284 where the implementation of the type check in function FOO
285 includes a full call to %TYPEP. There are also some fundamental problems
286 with the interpretation of VALUES types (inherited from CMU CL, and
287 from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
288 mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
291 The definitions of SIGCONTEXT-FLOAT-REGISTER and
292 %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
293 supported on FreeBSD because the floating point state is not saved,
294 but at least as of FreeBSD 4.0, the floating point state *is* saved,
295 so they could be supported after all. Very likely
296 SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
299 (as discussed by Douglas Crosher on the cmucl-imp mailing list ca.
300 Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
301 issue with 'union, 'and, 'or etc. So even though according to the
302 ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
303 (and now SBCL) interpret them as legal types.
306 ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
307 CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
308 list, and it is probably possible to use substantially the same
309 patches to add it to SBCL.
312 a slew of floating-point-related errors reported by Peter Van Eynde
314 a: (fixed in sbcl-0.6.11.25)
315 b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
316 should probably be 1.4012985e-45. In SBCL,
317 (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
318 than LEAST-POSITIVE-SHORT-FLOAT. Similar problems
319 exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
320 and LEAST-NEGATIVE-LONG-FLOAT.
321 c: Many expressions generate floating infinity:
326 PVE's regression tests want them to raise errors. SBCL
327 generates the infinities instead, which may or may not be
329 d: (in section12.erg) various forms a la
330 (FLOAT 1 DOUBLE-FLOAT-EPSILON)
331 don't give the right behavior.
334 type safety errors reported by Peter Van Eynde July 25, 2000:
335 a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
337 In general lengths of array type specifications aren't
338 checked by COERCE, so it fails when the spec is
339 (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
340 b: CONCATENATE has the same problem of not checking the length
341 of specified output array types. MAKE-SEQUENCE and MAP and
342 MERGE also have the same problem.
343 c: (COERCE 'AND 'FUNCTION) returns something related to
344 (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
345 d: ELT signals SIMPLE-ERROR if its index argument
346 isn't a valid index for its sequence argument, but should
347 signal TYPE-ERROR instead.
348 e: FILE-LENGTH is supposed to signal a type error when its
349 argument is not a stream associated with a file, but doesn't.
350 f: (FLOAT-RADIX 2/3) should signal an error instead of
352 g: (LOAD "*.lsp") should signal FILE-ERROR.
353 h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
354 should signal TYPE-ERROR.
355 i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
356 be used for input and output as needed. It should fail with
357 TYPE-ERROR when handed e.g. the results of
358 MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
359 the inappropriate positions, but doesn't.
360 j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
362 should probably signal an error instead of making a pathname with
364 k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
365 not a binary input stream, but instead cheerfully reads from
366 character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
369 DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
370 a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
372 b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
373 signal a PROGRAM-ERROR, and doesn't.
374 c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
375 and other DEFCLASS forms with duplicate specifications in their
376 slots, should signal a PROGRAM-ERROR, and doesn't.
377 d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
378 causes a COMPILER-ERROR.
381 SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
382 a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal
383 PROGRAM-ERROR, but SBCL accepts it instead.
384 b: SYMBOL-MACROLET should refuse to bind something which is
385 declared as a global variable, signalling PROGRAM-ERROR.
386 c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
387 it binds is declared SPECIAL inside.
390 LOOP bugs reported by Peter Van Eynde July 25, 2000:
391 a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
392 the definition of WITH clauses given in the ANSI spec, but
393 compiles and runs happily in SBCL.
394 b: a messy one involving package iteration:
395 interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<))))
396 Should be: (("blah" "blah2") ("blah2"))
397 SBCL: (("blah") ("blah2"))
398 * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
399 doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
402 type system errors reported by Peter Van Eynde July 25, 2000:
403 a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
404 but should be (VALUES T T) instead.
405 b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL
406 but should be (VALUES T T) instead.
407 c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
408 d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
409 blows up at the level of SPECIFIER-TYPE with
410 "Lower bound (0) is greater than upper bound (0)." Probably
411 SPECIFIER-TYPE should return NIL instead.
412 e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
413 "Component type for Complex is not numeric: (EQL 0)."
414 This might be easy to fix; the type system already knows
415 that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
416 f: The type system doesn't know about the condition system,
417 so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL.
418 g: The type system isn't all that smart about relationships
419 between hairy types, as shown in the type.erg test results,
420 e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
423 miscellaneous errors reported by Peter Van Eynde July 25, 2000:
425 (DEFGENERIC FOO02 (X))
426 (DEFMETHOD FOO02 ((X NUMBER)) T)
427 (LET ((M (FIND-METHOD (FUNCTION FOO02)
429 (LIST (FIND-CLASS (QUOTE NUMBER))))))
430 (REMOVE-METHOD (FUNCTION FOO02) M)
431 (DEFGENERIC FOO03 (X))
432 (ADD-METHOD (FUNCTION FOO03) M)))
433 should give an error, but SBCL allows it.
434 b: READ should probably return READER-ERROR, not the bare
435 arithmetic error, when input a la "1/0" or "1e1000" causes
439 It has been reported (e.g. by Peter Van Eynde) that there are
440 several metaobject protocol "errors". (In order to fix them, we might
441 need to document exactly what metaobject protocol specification
442 we're following -- the current code is just inherited from PCL.)
445 another error from Peter Van Eynde 5 September 2000:
446 (FORMAT NIL "~F" "FOO") should work, but instead reports an error.
447 PVE submitted a patch to deal with this bug, but it exposes other
448 comparably serious bugs, so I didn't apply it. It looks as though
449 the FORMAT code needs a fair amount of rewriting in order to comply
450 with the various details of the ANSI spec.
453 The implementation of #'+ returns its single argument without
454 type checking, e.g. (+ "illegal") => "illegal".
457 Attempting to use COMPILE on something defined by DEFMACRO fails:
458 (DEFMACRO FOO (X) (CONS X X))
460 Error in function C::GET-LAMBDA-TO-COMPILE:
461 #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
464 (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
465 Note: I looked into fixing this in 0.6.11.15, but gave up. The
466 problem seems to be that there are two relevant type methods for
467 the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
468 INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
469 called. This could be fixed, but type dispatch is messy and
470 confusing enough already, I don't want to complicate it further.
471 Perhaps someday we can make CLOS cross-compiled (instead of compiled
472 after bootstrapping) so that we don't need to have the type system
473 available before CLOS, and then we can rewrite the type methods to
474 CLOS methods, and then expressing the solutions to stuff like this
475 should become much more straightforward. -- WHN 2001-03-14
478 The debugger LIST-LOCATIONS command doesn't work properly.
481 Compiling and loading
482 (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
484 then requesting a BACKTRACE at the debugger prompt gives no information
485 about where in the user program the problem occurred.
488 The compiler is supposed to do type inference well enough that
491 ((SIMPLE-ARRAY SINGLE-FLOAT)
493 (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
496 is redundant. However, as reported by Juan Jose Garcia Ripoll for
497 CMU CL, it sometimes doesn't. Adding declarations is a pretty good
498 workaround for the problem for now, but can't be done by the TYPECASE
499 macros themselves, since it's too hard for the macro to detect
500 assignments to the variable within the clause.
501 Note: The compiler *is* smart enough to do the type inference in
502 many cases. This case, derived from a couple of MACROEXPAND-1
503 calls on Ripoll's original test case,
505 (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
506 (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
507 (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
508 (LET ((I 0) (G2554 LENGTH))
509 (DECLARE (TYPE REAL G2554) (TYPE REAL I))
512 (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
513 (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
514 (GO SB-LOOP::NEXT-LOOP)
515 SB-LOOP::END-LOOP))))))
516 demonstrates the problem; but the problem goes away if the TAGBODY
517 and GO forms are removed (leaving the SETF in ordinary, non-looping
518 code), or if the TAGBODY and GO forms are retained, but the
519 assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
522 Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
523 I am looking into this problem that showed up on the cmucl-help
524 list. It seems to me that the "implementation specific environment
525 hacking functions" found in pcl/walker.lisp are completely messed
526 up. The good thing is that they appear to be barely used within
527 PCL and the munged environment object is passed to cmucl only
528 in calls to macroexpand-1, which is probably why this case fails.
529 SBCL uses essentially the same code, so if the environment hacking
530 is screwed up, it affects us too.
533 Using the pretty-printer from the command prompt gives funny
534 results, apparently because the pretty-printer doesn't know
535 about user's command input, including the user's carriage return
536 that the user, and therefore the pretty-printer thinks that
537 the new output block should start indented 2 or more characters
538 rightward of the correct location.
541 (probably related to bug #70; maybe related to bug #109)
542 As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
544 (in-package "CL-USER")
545 (defun equal-terms (termx termy)
547 ((alpha-equal-bound-term-lists (listx listy)
548 (or (and (null listx) (null listy))
550 (let ((bindings-x (bindings-of-bound-term (car listx)))
551 (bindings-y (bindings-of-bound-term (car listy))))
552 (if (and (null bindings-x) (null bindings-y))
553 (alpha-equal-terms (term-of-bound-term (car listx))
554 (term-of-bound-term (car listy)))
555 (and (= (length bindings-x) (length bindings-y))
557 (enter-binding-pairs (bindings-of-bound-term (car listx))
558 (bindings-of-bound-term (car listy)))
559 (alpha-equal-terms (term-of-bound-term (car listx))
560 (term-of-bound-term (car listy)))
561 (exit-binding-pairs (bindings-of-bound-term (car listx))
562 (bindings-of-bound-term (car listy)))))))
563 (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
565 (alpha-equal-terms (termx termy)
566 (if (and (variable-p termx)
568 (equal-bindings (id-of-variable-term termx)
569 (id-of-variable-term termy))
570 (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
571 (alpha-equal-bound-term-lists (bound-terms-of-term termx)
572 (bound-terms-of-term termy))))))
576 (with-variable-invocation (alpha-equal-terms termx termy))))))
577 causes an assertion failure
578 The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
579 (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
581 Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
582 case with the same problem:
583 (defun parse-fssp-alignment ()
584 ;; Given an FSSP alignment file named by the argument . . .
585 (labels ((get-fssp-char ()
589 ;; Stub body, enough to tickle the bug.
590 (list (read-fssp-char)
594 ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
595 a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
596 (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
597 This also leads to funny behavior when derived type specifiers
598 are used, as originally reported by Milan Zamazal for CMU CL (on the
599 Debian bugs mailing list (?) 2000-02-27), then reported by Martin
600 Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
601 (DEFTYPE FOO () 'SIMPLE-ARRAY)
602 (CONCATENATE 'FOO #(1 2) '(3))
603 => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
605 The derived type specifier FOO should act the same way as the
606 built-in type SIMPLE-ARRAY here, but it doesn't. That problem
607 doesn't seem to exist for sequence types:
608 (DEFTYPE BAR () 'SIMPLE-VECTOR)
609 (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
612 As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
613 and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
614 crashes SBCL. In general tracing anything which is used in the
615 implementation of TRACE is likely to have the same problem.
618 As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
619 SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
620 notably including all PCL instances. There's a limit to how much
621 SXHASH can do to return unique values for instances, but at least
622 it should probably look at the class name, the way that it does
623 for STRUCTURE-OBJECTs.
626 As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
627 > There remains one issue, that is a bug in SBCL:
628 > According to my interpretation of the spec, the ":" and "@" modifiers
629 > should appear _after_ the comma-seperated arguments.
630 > Well, SBCL (and CMUCL for that matter) accept
631 > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) " 1"))
632 > where the correct way (IMHO) should be
633 > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) " 1"))
634 Probably SBCL should stop accepting the "~:8D"-style format arguments,
635 or at least issue a warning.
638 (probably related to bug #65; maybe related to bug #109)
639 The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
641 (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
642 (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
643 (LET ((ITEM (FIRST SEQ)))
646 ((FUNCALL TEST OBJ ITEM)
649 (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
650 (FIND-ITEM ITEM SEQUENCE TEST)))
651 from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
652 causes sbcl-0.6.9 to fail with
653 error in function SB-KERNEL:ASSERT-ERROR:
654 The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
655 (SB-C::LAMBDA-TAIL-SET
656 (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
659 (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after
660 (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
661 the previous SPEED policy. This bug will probably get fixed in
662 0.6.9.x in a general cleanup of optimization policy.
665 (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
668 As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
669 gives a result which isn't COMPLEX. The result type optimizer
670 for COERCE doesn't know this, perhaps because it was written before
671 ANSI threw this curveball: the optimizer thinks that COERCE always
672 returns a result of the specified type. Thus while the interpreted
674 (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
675 returns the correct result,
677 the compiled function
683 As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
684 ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
685 :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
686 WITH-OUTPUT-TO-STRING.
689 ANSI says in one place that type declarations can be abbreviated even
690 when the type name is not a symbol, e.g.
691 (DECLAIM ((VECTOR T) *FOOVECTOR*))
692 SBCL doesn't support this. But ANSI says in another place that this
693 isn't allowed. So it's not clear this is a bug after all. (See the
694 e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
698 as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
699 The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
700 an easily guessable temporary filename in a way which might open
701 applications using LOAD-FOREIGN to hijacking by malicious users
702 on the same machine. Incantations for doing this safely are
703 floating around the net in various "how to write secure programs
704 despite Unix" documents, and it would be good to (1) fix this in
705 LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
706 files and make it share the same new safe logic.
709 (fixed early Feb 2001 by MNA)
712 As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
715 (loop with (a . b) of-type float = '(0.0 . 1.0)
716 and (c . d) of-type float = '(2.0 . 3.0)
717 return (list a b c d))
718 should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
719 invokes the debugger: "B is not of type list".
720 SBCL does the same thing.
723 Functions are assigned names based on the context in which they're
724 defined. This is less than ideal for the functions which are
725 used to implement CLOS methods. E.g. the output of
726 (DESCRIBE 'PRINT-OBJECT) lists functions like
727 #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}>
729 #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
730 It would be better if these functions' names always identified
731 them as methods, and identified their generic functions and
735 RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
736 RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
737 the mean of the distribution can be systematically O(0.1%) wrong.
738 Just increasing R-I-E-B is probably not a good solution, since
739 it would decrease efficiency more than is probably necessary. Perhaps
740 using some sort of accept/reject method would be better.
743 (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
746 Internally the compiler sometimes evaluates
747 (sb-kernel:type/= (specifier-type '*) (specifier-type t))
748 (I stumbled across this when I added an
749 (assert (not (eq type1 *wild-type*)))
750 in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
751 in a type context should probably be translated to T, and so it's
752 probably to ask whether it's equal to the T type and then (using the
753 EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
754 (I haven't tried to investigate this bug enough to guess whether
755 there might be any user-level symptoms.)
758 a latent cross-compilation/bootstrapping bug: The cross-compilation
759 host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
760 and possibly elsewhere. Instead, we should use the target system's
761 CHAR-CODE-LIMIT. This will probably cause problems if we try to
762 bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
766 (subtypep '(or (integer -1 1)
770 (integer -1 1))) => NIL,T
771 An analogous problem with SINGLE-FLOAT and REAL types was fixed in
772 sbcl-0.6.11.22, but some peculiarites of the RATIO type make it
773 awkward to generalize the fix to INTEGER and RATIONAL. It's not
774 clear what's the best fix. (See the "bug in type handling" discussion
775 on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
778 In sbcl-0.6.11.26, (COMPILE 'IN-HOST-COMPILATION-MODE) in
779 src/cold/shared.lisp doesn't correctly translate the
781 (defun in-host-compilation-mode (fn)
782 (let ((*features* (cons :sb-xc-host *features*))
783 ;; the CROSS-FLOAT-INFINITY-KLUDGE, as documented in
784 ;; base-target-features.lisp-expr:
785 (*shebang-features* (set-difference *shebang-features*
786 '(:sb-propagate-float-type
787 :sb-propagate-fun-type))))
788 (with-additional-nickname ("SB-XC" "SB!XC")
790 No error is reported by the compiler, but when the function is executed,
792 TYPE-ERROR in SB-KERNEL::OBJECT-NOT-TYPE-ERROR-HANDLER:
793 (:LINUX :X86 :IEEE-FLOATING-POINT :SB-CONSTRAIN-FLOAT-TYPE :SB-TEST
794 :SB-INTERPRETER :SB-DOC :UNIX ...) is not of type SYMBOL.
797 Inconsistencies between derived and declared VALUES return types for
798 DEFUN aren't checked very well. E.g. the logic which successfully
799 catches problems like
800 (declaim (ftype (function (fixnum) float) foo))
802 (declare (type integer x))
803 (values x)) ; wrong return type, detected, gives warning, good!
805 (declaim (ftype (function (t) (values t t)) bar))
807 (values x)) ; wrong number of return values, no warning, bad!
808 The cause of this is seems to be that (1) the internal function
809 VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
810 arguments symmetrically, and (2) when the type checking code was
811 written back when when SBCL's code was still CMU CL, the intent
813 (declaim (ftype (function (t) t) bar))
815 (values x x)) ; wrong number of return values; should give warning?
816 not be warned for, because a two-valued return value is considered
817 to be compatible with callers who expects a single value to be
818 returned. That intent is probably not appropriate for modern ANSI
819 Common Lisp, but fixing this might be complicated because of other
820 divergences between auld-style and new-style handling of
821 multiple-VALUES types. (Some issues related to this were discussed
822 on cmucl-imp at some length sometime in 2000.)
825 The facility for dumping a running Lisp image to disk gets confused
826 when run without the PURIFY option, and creates an unnecessarily large
827 core file (apparently representing memory usage up to the previous
828 high-water mark). Moreover, when the file is loaded, it confuses the
829 GC, so that thereafter memory usage can never be reduced below that
833 The TRACE facility can't be used on some kinds of functions.
834 (Basically, the breakpoint facility was incompletely implemented
835 in the X86 port of CMU CL, and hasn't been fixed in SBCL.)
838 In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
839 CL), out-of-line structure slot setters are horribly inefficient
840 whenever the type of the slot is declared, because out-of-line
841 structure slot setters are implemented as closures to save space,
842 so the compiler doesn't compile the type test into code, but
843 instead just saves the type in a lexical closure and interprets it
845 A proper solution involves deciding whether it's really worth
846 saving space by implementing structure slot accessors as closures.
847 (If it's not worth it, the problem vanishes automatically. If it
848 is worth it, there are hacks we could use to force type tests to
849 be compiled anyway, and even shared. E.g. we could implement
850 an EQUAL hash table mapping from types to compiled type tests,
851 and save the appropriate compiled type test as part of each lexical
852 closure; or we could make the lexical closures be placeholders
853 which overwrite their old definition as a lexical closure with
854 a new compiled definition the first time that they're called.)
855 As a workaround for the problem, #'(SETF FOO) expressions can
856 be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
857 (defmacro efficient-setf-function (place-function-name)
858 (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
859 ;; a workaround for the problem, encouraging the
860 ;; inline expansion of the structure accessor, so
861 ;; that the compiler can optimize its type test
862 (let ((new-value (gensym "NEW-VALUE-"))
863 (structure-value (gensym "STRUCTURE-VALUE-")))
864 `(lambda (,new-value ,structure-value)
865 (setf (,place-function-name ,structure-value)
867 ;; no problem, can just use the ordinary expansion
868 `(function (setf ,place-function-name))))
871 DESCRIBE interacts poorly with *PRINT-CIRCLE*, e.g. the output from
872 (let ((*print-circle* t)) (describe (make-hash-table)))
874 #<HASH-TABLE :TEST EQL :COUNT 0 {90BBFC5}> is an . (EQL)
876 Its REHASH-SIZE is 1.5. Its REHASH-THRESHOLD is . (1.0)
877 It holds 0 key/value pairs.
878 where the ". (EQL)" and ". (1.0)" substrings are screwups.
879 (This is likely a pretty-printer problem which happens to
880 be exercised by DESCRIBE, not actually a DESCRIBE problem.)
883 There's apparently a bug in CEILING optimization which caused
884 Douglas Crosher to patch the CMU CL version. Martin Atzmueller
885 applied the patches to SBCL and they didn't seem to cause problems
886 (as reported sbcl-devel 2001-05-04). However, since the patches
887 modify nontrivial code which was apparently written incorrectly
888 the first time around, until regression tests are written I'm not
889 comfortable merging the patches in the CVS version of SBCL.
892 The error message for calls to structure accessors with the
893 wrong number of arguments is confusing and of the wrong
894 condition class (TYPE-ERROR instead of PROGRAM-ERROR):
895 * (defstruct foo x y)
897 debugger invoked on condition of type SIMPLE-TYPE-ERROR:
898 Structure for accessor FOO-X is not a FOO:
902 As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
903 requires that SYMBOL-MACROLET refuse to rebind special variables,
904 but SBCL doesn't do this. (Also as reported by AL in the same
905 message, SBCL depended on this nonconforming behavior to build
906 itself, because of the way that **CURRENT-SEGMENT** was implemented.
907 As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
908 has been fixed, but the nonconforming behavior remains.)
911 As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI's
912 definition of (LOOP .. DO ..) requires that the terms following
913 DO all be compound forms. SBCL's implementation of LOOP allows
914 non-compound forms (like the bare symbol COUNT, in his example)
918 (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
922 in #<PACKAGE "SB-ALIEN">.
923 Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
924 Macro arguments: (#:whole-470 #:environment-471)
925 On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
926 /usr/stuff/sbcl/src/code/host-alieneval.lisp
927 Created: Monday, March 12, 2001 07:47:43 AM CST
930 (DESCRIBE 'STREAM-READ-BYTE)
933 (reported by Eric Marsden on cmucl-imp 2001-06-15)
935 (TYPEP 0 '(COMPLEX (EQL 0)))
936 signals an error in sbcl-0.6.12.34,
937 The component type for COMPLEX is not numeric: (EQL 0)
938 This is funny since sbcl-0.6.12.34 knows
939 (SUBTYPEP '(EQL 0) 'NUMBER) => T
942 (TIME (ROOM T)) reports more than 200 Mbytes consed even for
943 a clean, just-started SBCL system. And it seems to be right:
944 (ROOM T) can bring a small computer to its knees for a *long*
945 time trying to GC afterwards. Surely there's some more economical
946 way to implement (ROOM T).
949 reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
951 ;;; This file fails to compile.
952 ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
953 (in-package :cl-user)
959 ;; Uncomment and it works
962 In SBCL 0.6.12.42, the problem is
963 internal error, failed AVER:
964 "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
965 (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
968 reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
970 ;;; The compiler is flushing the argument type test, and the default
971 ;;; case in the cond, so that calling with say a fixnum 0 causes a
973 (declaim (optimize (safety 2) (speed 3)))
975 (declare (type (or string stream) x))
976 (cond ((typep x 'string) 'string)
977 ((typep x 'stream) 'stream)
980 The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
981 (not the SIGBUS reported in the comment) but that's broken too;
982 type declarations are supposed to be treated as assertions unless
983 SAFETY 0, so we should be getting a TYPE-ERROR.
986 reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
988 (in-package :cl-user)
989 ;;; Produces an assertion failures when compiled.
991 (declare (type (or (function (t) t) null) z))
992 (let ((z (or z #'identity)))
993 (declare (type (function (t) t) z))
995 The error in sbcl-0.6.12.42 is
996 internal error, failed AVER:
997 "(COMMON-LISP:NOT (COMMON-LISP:EQ SB!C::CHECK COMMON-LISP:T))"
1000 reported by Martin Atzmueller 2001-06-25; taken from CMU CL bugs
1001 collection; apparently originally reported by Bruno Haible
1002 (in-package :cl-user)
1003 ;;; From: Bruno Haible
1004 ;;; Subject: scope of SPECIAL declarations
1005 ;;; It seems CMUCL has a bug relating to the scope of SPECIAL
1006 ;;; declarations. I observe this with "CMU Common Lisp 18a x86-linux
1009 (declare (special x))
1012 (declare (special x)) y)))
1013 ;;; Gives: 0 (this should return 1 according to CLHS)
1015 (declare (special x))
1018 (declare (special x)) y)))
1019 ;;; Gives: 1 (correct).
1020 The reported results match what we get from the interpreter
1024 reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
1026 (in-package :cl-user)
1027 ;;; From: David Gadbois <gadbois@cyc.com>
1029 ;;; Logical pathnames aren't externalizable.
1031 (let ((tempfile "/tmp/test.lisp"))
1032 (setf (logical-pathname-translations "XXX")
1033 '(("XXX:**;*.*" "/tmp/**/*.*")))
1034 (with-open-file (out tempfile :direction :output)
1035 (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
1036 (compile-file tempfile))
1037 The error message in sbcl-0.6.12.42 is
1039 ; (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
1040 ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
1043 reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
1045 (in-package :cl-user)
1046 ;;; This file causes the byte compiler to fail.
1047 (declaim (optimize (speed 0) (safety 1)))
1050 (multiple-value-list
1052 (return-from tst1)))))
1053 The error message in sbcl-0.6.12.42 is
1054 internal error, failed AVER:
1055 "(COMMON-LISP:EQUAL (SB!C::BYTE-BLOCK-INFO-START-STACK SB!INT:INFO) SB!C::STACK)"
1058 reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
1060 (in-package :cl-user)
1061 ;;; The following invokes a compiler error.
1062 (declaim (optimize (speed 2) (debug 3)))
1065 (unwind-protect nil)))
1069 The error message in sbcl-0.6.12.42 is
1070 internal error, failed AVER:
1071 "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)"
1074 When the compiler inline expands functions, it may be that different
1075 kinds of return values are generated from different code branches.
1076 E.g. an inline expansion of POSITION generates integer results
1077 from one branch, and NIL results from another. When that inline
1078 expansion is used in a context where only one of those results
1081 (aref *a1* (position x *a2*)))
1082 and the compiler can't prove that the unacceptable branch is
1083 never taken, then bogus type mismatch warnings can be generated.
1084 If you need to suppress the type mismatch warnings, you can
1085 suppress the inline expansion,
1087 #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
1088 (aref *a1* (position x *a2*)))
1089 or, sometimes, suppress them by declaring the result to be of an
1092 (aref *a1* (the integer (position x *a2*))))
1094 This is not a new compiler problem in 0.7.0, but the new compiler
1095 transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it
1096 more conspicuous. If you don't need performance from these functions,
1097 and the bogus warnings are a nuisance for you, you can return to
1098 your pre-0.7.0 state of grace with
1099 #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
1102 as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
1103 (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
1104 (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
1105 when of course it should be NIL. (He says it only fails for X86,
1106 not SPARC; dunno about Alpha.)
1108 Also, "the same problem exists for LONG-FLOAT-EPSILON,
1109 DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
1110 for the -negative- the + is replaced by a - in the test)."
1112 Raymond Toy comments that this is tricky on the X86 since its FPU
1113 uses 80-bit precision internally.
1116 a bug in the byte compiler and/or interpreter: Compile
1117 (IN-PACKAGE :CL-USER)
1118 (DECLAIM (OPTIMIZE (SPEED 0) (SAFETY 1) (DEBUG 1)))
1119 (DEFUN BAR (&REST DIMS)
1120 (IF (EVERY #'INTEGERP DIMS)
1123 then execute (BAR '(1 2 3 4)). In sbcl-0.pre7.14.flaky4.8
1124 this gives a TYPE-ERROR,
1125 The value #:UNINITIALIZED-EVAL-STACK-ELEMENT is not
1126 of type (MOD 536870911).
1127 The same error will probably occur in earlier versions as well,
1128 although the name of the uninitialized-element placeholder will
1131 The same thing happens if the compiler macro expansion of
1132 EVERY into MAP is hand-expanded:
1134 (if (block blockname
1137 (let ((pred-value (funcall #'integerp dim)))
1139 (return-from blockname
1145 CMU CL doesn't have this compiler macro expansion, so it was
1146 immune to the original bug in BAR, but once we hand-expand it
1147 into BAR2, CMU CL 18c has the same bug. (Run (BAR '(NIL NIL)).)
1149 The native compiler handles it fine, both in SBCL and in CMU CL.
1152 The compiler incorrectly figures the return type of
1153 (DEFUN FOO (FRAME UP-FRAME)
1160 This problem exists in CMU CL 18c too. When I reported it on
1161 cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with
1162 a partial explanation, but no fix has been found yet.
1165 Even in sbcl-0.pre7.x, which is supposed to be free of the old
1166 non-ANSI behavior of treating the function return type inferred
1167 from the current function definition as a declaration of the
1168 return type from any function of that name, the return type of NIL
1169 is attached to FOO in 120a above, and used to optimize code which
1173 There was some sort of screwup in handling of
1174 (IF (NOT (IGNORE-ERRORS ..))). E.g.
1176 (if (not (ignore-errors
1177 (make-pathname :host "foo" :directory "!bla" :name "bar")))
1179 (error "notunlessnot")))
1180 The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
1181 printing "ok", but instead it's going to the ERROR. This problem
1182 seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
1183 2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
1184 I reverted back to the old weird HANDLER-CASE code. However, I
1185 think the problem looks like a compiler bug in handling RETURN-FROM,
1186 so I left the MNA-patched code in HANDLER-CASE (suppressed with
1187 #+NIL) and I'd like to go back to see whether this really is
1188 a compiler bug before I delete this BUGS entry.
1191 The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
1192 (IN-PACKAGE :SB-KERNEL)
1193 (TYPE= (SPECIFIER-TYPE '(VECTOR T))
1194 (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
1195 Then because of this, the compiler bogusly optimizes
1196 (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
1197 to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to
1198 NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
1199 about type mismatches (probably harmlessly, another instance of bug 117);
1200 and then cold init died with a segmentation fault.
1203 As of version 0.pre7.14, SBCL's implementation of MACROLET makes
1204 the entire lexical environment at the point of MACROLET available
1205 in the bodies of the macroexpander functions. In particular, it
1206 allows the function bodies (which run at compile time) to try to
1207 access lexical variables (which are only defined at runtime).
1208 It doesn't even issue a warning, which is bad.
1210 The SBCL behavior arguably conforms to the ANSI spec (since the
1211 spec says that the behavior is undefined, ergo anything conforms).
1212 However, it would be better to issue a compile-time error.
1213 Unfortunately I (WHN) don't see any simple way to detect this
1214 condition in order to issue such an error, so for the meantime
1215 SBCL just does this weird broken "conforming" thing.
1217 The ANSI standard says, in the definition of the special operator
1219 The macro-expansion functions defined by MACROLET are defined
1220 in the lexical environment in which the MACROLET form appears.
1221 Declarations and MACROLET and SYMBOL-MACROLET definitions affect
1222 the local macro definitions in a MACROLET, but the consequences
1223 are undefined if the local macro definitions reference any
1224 local variable or function bindings that are visible in that
1225 lexical environment.
1226 Then it seems to contradict itself by giving the example
1228 (macrolet ((fudge (z)
1229 ;The parameters x and flag are not accessible
1230 ; at this point; a reference to flag would be to
1231 ; the global variable of that name.
1232 ` (if flag (* ,z ,z) ,z)))
1233 ;The parameters x and flag are accessible here.
1237 The comment "a reference to flag would be to the global variable
1238 of the same name" sounds like good behavior for the system to have.
1239 but actual specification quoted above says that the actual behavior
1242 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
1244 (Note: At some point, the pure interpreter (actually a semi-pure
1245 interpreter aka "the IR1 interpreter") will probably go away, replaced
1247 (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
1248 and at that time these bugs should either go away automatically or
1249 become more tractable to fix. Until then, they'll probably remain,
1250 since some of them aren't considered urgent, and the rest are too hard
1251 to fix as long as so many special cases remain. After the IR1
1252 interpreter goes away is also the preferred time to start
1253 systematically exterminating cases where debugging functionality
1254 (backtrace, breakpoint, etc.) breaks down, since getting rid of the
1255 IR1 interpreter will reduce the number of special cases we need to
1259 The FUNCTION special operator doesn't check properly whether its
1260 argument is a function name. E.g. (FUNCTION (X Y)) returns a value
1261 instead of failing with an error. (Later attempting to funcall the
1262 value does cause an error.)
1265 COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
1266 * (DEFUN FOO (X) (- 12 X))
1268 * (COMPILED-FUNCTION-P #'FOO)
1273 (DEFVAR *SUPPRESS-P* T)
1274 (EVAL '(UNLESS *SUPPRESS-P*
1275 (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
1276 (FORMAT T "surprise!"))))
1277 prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
1278 rewritten from scratch to conform to the ANSI definition, abandoning
1279 the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
1280 in the original CMU CL source, too). This should be easier to do --
1281 though still nontrivial -- once the various IR1 interpreter special
1285 EVAL-WHEN's idea of what's a toplevel form is even more screwed up
1286 than the example in IR1-3 would suggest, since COMPILE-FILE and
1287 COMPILE both print both "right now!" messages when compiling the
1291 (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
1292 (PRINT "yes! right now!"))
1295 (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
1296 (PRINT "no! right now!"))
1298 and while EVAL doesn't print the "right now!" messages, the first
1299 FUNCALL on the value returned by EVAL causes both of them to be printed.
1302 The system accepts DECLAIM in most places where DECLARE would be
1303 accepted, without even issuing a warning. ANSI allows this, but since
1304 it's fairly easy to mistype DECLAIM instead of DECLARE, and the
1305 meaning is rather different, and it's unlikely that the user
1306 has a good reason for doing DECLAIM not at top level, it would be
1307 good to issue a STYLE-WARNING when this happens. A possible
1308 fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
1309 or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
1310 [This is considered an IR1-interpreter-related bug because until
1311 EVAL-WHEN is rewritten, which won't happen until after the IR1
1312 interpreter is gone, the system's notion of what's a top-level form
1313 and what's not will remain too confused to fix this problem.]
1316 (another wishlist thing..) Reimplement DEFMACRO to be basically
1317 like DEFMACRO-MUNDANELY, just using EVAL-WHEN.