0.7.2.7:
[sbcl.git] / BUGS
1 REPORTING BUGS
2
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
7
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?
12 but instead
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))
18                                           (PRINT X Y)))))
19          X Y)
20      then at the command line type
21        (MAKE-FOO)
22      the program loops endlessly instead of printing the object.
23
24
25 NOTES:
26
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.
29
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).
33
34
35 KNOWN BUGS OF NO SPECIAL CLASS:
36
37 2:
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.
44
45 3:
46   ANSI specifies that a type mismatch in a structure slot
47   initialization value should not cause a warning.
48 WORKAROUND:
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, and (3) by their own reasoning, it looks as though
54   ANSI may have gotten it wrong. ANSI justifies this specification
55   by saying 
56     The restriction against issuing a warning for type mismatches
57     between a slot-initform and the corresponding slot's :TYPE
58     option is necessary because a slot-initform must be specified
59     in order to specify slot options; in some cases, no suitable
60     default may exist.
61   However, in SBCL (as in CMU CL or, for that matter, any compiler
62   which really understands Common Lisp types) a suitable default
63   does exist, in all cases, because the compiler understands the
64   concept of functions which never return (i.e. has return type NIL).
65   Thus, as a portable workaround, you can use a call to some
66   known-never-to-return function as the default. E.g.
67     (DEFSTRUCT FOO
68       (BAR (ERROR "missing :BAR argument")
69            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
70   or 
71     (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
72     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
73       (ERROR "missing required argument")) 
74     (DEFSTRUCT FOO
75       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
76       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
77       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
78   Such code should compile without complaint and work correctly either
79   on SBCL or on any other completely compliant Common Lisp system.
80
81 6:
82   bogus warnings about undefined functions for magic functions like
83   SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
84   like src/code/float.lisp. Fixing this will probably require
85   straightening out enough bootstrap consistency issues that
86   the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
87   Instead, the cross-compiler runs in a slightly flaky state
88   which is sane enough to compile SBCL itself, but which is
89   also unstable in several ways, including its inability
90   to really grok function declarations.
91
92 7:
93   The "compiling top-level form:" output ought to be condensed.
94   Perhaps any number of such consecutive lines ought to turn into a
95   single "compiling top-level forms:" line.
96
97 10:
98   The way that the compiler munges types with arguments together
99   with types with no arguments (in e.g. TYPE-EXPAND) leads to
100   weirdness visible to the user:
101         (DEFTYPE FOO () 'FIXNUM)
102         (TYPEP 11 'FOO) => T
103         (TYPEP 11 '(FOO)) => T, which seems weird
104         (TYPEP 11 'FIXNUM) => T
105         (TYPEP 11 '(FIXNUM)) signals an error, as it should
106   The situation is complicated by the presence of Common Lisp types
107   like UNSIGNED-BYTE (which can either be used in list form or alone)
108   so I'm not 100% sure that the behavior above is actually illegal.
109   But I'm 90+% sure, and the following related behavior,
110         (TYPEP 11 'AND) => T
111   treating the bare symbol AND as equivalent to '(AND), is specifically
112   forbidden (by the ANSI specification of the AND type).
113
114 11:
115   It would be nice if the
116         caught ERROR:
117           (during macroexpansion)
118   said what macroexpansion was at fault, e.g.
119         caught ERROR:
120           (during macroexpansion of IN-PACKAGE,
121           during macroexpansion of DEFFOO)
122
123 15:
124   (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
125             '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
126   (Also, when this is fixed, we can enable the code in PROCLAIM which 
127   checks for incompatible FTYPE redeclarations.)
128
129 19:
130   (I *think* this is a bug. It certainly seems like strange behavior. But
131   the ANSI spec is scary, dark, and deep.. -- WHN)
132     (FORMAT NIL  "~,1G" 1.4) => "1.    "
133     (FORMAT NIL "~3,1G" 1.4) => "1.    "
134
135 20:
136   from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
137         (defclass ccc () ())
138         (setf (find-class 'ccc1) (find-class 'ccc))
139         (defmethod zut ((c ccc1)) 123)
140   In sbcl-0.7.1.13, this gives an error, 
141         There is no class named CCC1.
142   DTC's recommended workaround from the mailing list 3 Mar 2000:
143         (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
144
145 22:
146   The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
147   says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
148   inside "~<..~>" (without the colon modifier on the closing syntax).
149   However, SBCL doesn't do this:
150         * (FORMAT T "~<munge~wegnum~>" 12)
151         munge12egnum
152         NIL
153
154 27:
155   Sometimes (SB-EXT:QUIT) fails with 
156         Argh! maximum interrupt nesting depth (4096) exceeded, exiting
157         Process inferior-lisp exited abnormally with code 1
158   I haven't noticed a repeatable case of this yet.
159
160 31:
161   In some cases the compiler believes type declarations on array
162   elements without checking them, e.g.
163         (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1)))
164         (DEFSTRUCT FOO A B)
165         (DEFUN BAR (X)
166           (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X))
167           (WHEN (CONSP (AREF X 0))
168             (PRINT (AREF X 0))))
169         (BAR (VECTOR (MAKE-FOO :A 11 :B 12)))
170   prints
171         #S(FOO :A 11 :B 12) 
172   in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for
173   all cases, e.g. the type assumption *is* checked if the array
174   elements are declared to be of some structure type instead of CONS.
175
176 32:
177   The printer doesn't report closures very well. This is true in 
178   CMU CL 18b as well:
179     (PRINT #'CLASS-NAME)
180   gives
181     #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
182   It would be nice to make closures have a settable name slot,
183   and make things like DEFSTRUCT and FLET, which create closures,
184   set helpful values into this slot.
185
186 33:
187   And as long as we're wishing, it would be awfully nice if INSPECT could
188   also report on closures, telling about the values of the bound variables.
189
190 35:
191   The compiler assumes that any time a function of declared FTYPE
192   doesn't signal an error, its arguments were of the declared type.
193   E.g. compiling and loading
194     (DECLAIM (OPTIMIZE (SAFETY 3)))
195     (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
196     (DEFUN GAMMA (X) X)
197     (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
198     (DEFUN FOO (X)
199       (COND ((> (FACTORIAL X) 1.0E6)
200              (FORMAT T "too big~%"))
201             ((INTEGERP X)
202              (FORMAT T "exactly ~S~%" (FACTORIAL X)))
203             (T
204              (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
205   then executing
206     (FOO 1.5)
207   will cause the INTEGERP case to be selected, giving bogus output a la
208     exactly 1.33..
209   This violates the "declarations are assertions" principle.
210   According to the ANSI spec, in the section "System Class FUNCTION",
211   this is a case of "lying to the compiler", but the lying is done
212   by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
213   not by the unexpectedly general definition of FACTORIAL. In any case,
214   "declarations are assertions" means that lying to the compiler should
215   cause an error to be signalled, and should not cause a bogus
216   result to be returned. Thus, the compiler should not assume
217   that arbitrary functions check their argument types. (It might
218   make sense to add another flag (CHECKED?) to DEFKNOWN to 
219   identify functions which *do* check their argument types.)
220   (Also, verify that the compiler handles declared function
221   return types as assertions.)
222
223 41:
224   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
225         (DEFTYPE INDEXOID () '(INTEGER 0 1000))
226         (DEFUN FOO (X)
227           (DECLARE (TYPE INDEXOID X))
228           (THE (VALUES INDEXOID)
229             (VALUES X)))
230   where the implementation of the type check in function FOO 
231   includes a full call to %TYPEP. There are also some fundamental problems
232   with the interpretation of VALUES types (inherited from CMU CL, and
233   from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
234   mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
235
236 42:
237   The definitions of SIGCONTEXT-FLOAT-REGISTER and
238   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
239   supported on FreeBSD because the floating point state is not saved,
240   but at least as of FreeBSD 4.0, the floating point state *is* saved,
241   so they could be supported after all. Very likely 
242   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
243
244 43:
245   (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. 
246   Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
247   issue with 'union, 'and, 'or etc. So even though according to the
248   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
249   (and now SBCL) interpret them as legal types.
250
251 45:
252   a slew of floating-point-related errors reported by Peter Van Eynde
253   on July 25, 2000:
254         b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
255            should probably be 1.4012985e-45. In SBCL,
256            (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
257            than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
258            exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
259            and LEAST-NEGATIVE-LONG-FLOAT.
260         c: Many expressions generate floating infinity on x86/Linux:
261                 (/ 1 0.0)
262                 (/ 1 0.0d0)
263                 (EXPT 10.0 1000)
264                 (EXPT 10.0d0 1000)
265            PVE's regression tests want them to raise errors. sbcl-0.7.0.5
266            on x86/Linux generates the infinities instead. That might or
267            might not be conforming behavior, but it's also inconsistent,
268            which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
269            should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
270            generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
271            signals an error.
272         d: (in section12.erg) various forms a la 
273                 (FLOAT 1 DOUBLE-FLOAT-EPSILON)
274            don't give the right behavior.
275
276 46:
277   type safety errors reported by Peter Van Eynde July 25, 2000:
278         a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
279            => #(A B C)
280            In general lengths of array type specifications aren't
281            checked by COERCE, so it fails when the spec is
282            (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
283         b: CONCATENATE has the same problem of not checking the length
284            of specified output array types. MAKE-SEQUENCE and MAP and
285            MERGE also have the same problem.
286         c: (COERCE 'AND 'FUNCTION) returns something related to
287            (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
288         f: (FLOAT-RADIX 2/3) should signal an error instead of 
289            returning 2.
290         g: (LOAD "*.lsp") should signal FILE-ERROR.
291         h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
292            should signal TYPE-ERROR.
293         i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
294            be used for input and output as needed. It should fail with
295            TYPE-ERROR when handed e.g. the results of
296            MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
297            the inappropriate positions, but doesn't.
298         j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
299                             (QUOTE STRING)))
300            should probably signal an error instead of making a pathname with
301            a null byte in it.
302         k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
303            not a binary input stream, but instead cheerfully reads from
304            character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
305
306 47:
307   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
308         a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
309            doesn't.
310         b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
311            signal a PROGRAM-ERROR, and doesn't.
312         c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
313            and other DEFCLASS forms with duplicate specifications in their
314            slots, should signal a PROGRAM-ERROR, and doesn't.
315         d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
316            causes a COMPILER-ERROR.
317
318 48:
319   SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
320         a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal
321            PROGRAM-ERROR, but SBCL accepts it instead.
322         b: SYMBOL-MACROLET should refuse to bind something which is
323            declared as a global variable, signalling PROGRAM-ERROR.
324         c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
325            it binds is declared SPECIAL inside.
326
327 51:
328   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
329         a: (PROGN
330             (DEFGENERIC FOO02 (X))
331             (DEFMETHOD FOO02 ((X NUMBER)) T)
332             (LET ((M (FIND-METHOD (FUNCTION FOO02)
333                                   NIL
334                                   (LIST (FIND-CLASS (QUOTE NUMBER))))))
335               (REMOVE-METHOD (FUNCTION FOO02) M)
336               (DEFGENERIC FOO03 (X))
337               (ADD-METHOD (FUNCTION FOO03) M)))
338            should give an error, but SBCL allows it.
339         b: READ should probably return READER-ERROR, not the bare 
340            arithmetic error, when input a la "1/0" or "1e1000" causes
341            an arithmetic error.
342
343 52:
344   It has been reported (e.g. by Peter Van Eynde) that there are 
345   several metaobject protocol "errors". (In order to fix them, we might
346   need to document exactly what metaobject protocol specification
347   we're following -- the current code is just inherited from PCL.)
348
349 54:
350   The implementation of #'+ returns its single argument without
351   type checking, e.g. (+ "illegal") => "illegal".
352
353 58:
354   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
355   Note: I looked into fixing this in 0.6.11.15, but gave up. The
356   problem seems to be that there are two relevant type methods for
357   the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
358   INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
359   called. This could be fixed, but type dispatch is messy and
360   confusing enough already, I don't want to complicate it further.
361   Perhaps someday we can make CLOS cross-compiled (instead of compiled
362   after bootstrapping) so that we don't need to have the type system
363   available before CLOS, and then we can rewrite the type methods to
364   CLOS methods, and then expressing the solutions to stuff like this
365   should become much more straightforward. -- WHN 2001-03-14
366
367 60:
368   The debugger LIST-LOCATIONS command doesn't work properly.
369
370 61:
371   Compiling and loading
372     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
373     (FAIL 12)
374   then requesting a BACKTRACE at the debugger prompt gives no information
375   about where in the user program the problem occurred.
376
377 62:
378   The compiler is supposed to do type inference well enough that 
379   the declaration in
380     (TYPECASE X
381       ((SIMPLE-ARRAY SINGLE-FLOAT)
382        (LOCALLY
383          (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
384          ..))
385       ..)
386   is redundant. However, as reported by Juan Jose Garcia Ripoll for
387   CMU CL, it sometimes doesn't. Adding declarations is a pretty good
388   workaround for the problem for now, but can't be done by the TYPECASE
389   macros themselves, since it's too hard for the macro to detect
390   assignments to the variable within the clause. 
391     Note: The compiler *is* smart enough to do the type inference in
392   many cases. This case, derived from a couple of MACROEXPAND-1
393   calls on Ripoll's original test case,
394     (DEFUN NEGMAT (A)
395       (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
396       (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
397              (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
398                (LET ((I 0) (G2554 LENGTH))
399                  (DECLARE (TYPE REAL G2554) (TYPE REAL I))
400                  (TAGBODY
401                   SB-LOOP::NEXT-LOOP
402                   (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
403                   (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
404                   (GO SB-LOOP::NEXT-LOOP)
405                   SB-LOOP::END-LOOP))))))
406   demonstrates the problem; but the problem goes away if the TAGBODY
407   and GO forms are removed (leaving the SETF in ordinary, non-looping
408   code), or if the TAGBODY and GO forms are retained, but the 
409   assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
410
411 63:
412   Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
413     I am looking into this problem that showed up on the cmucl-help
414     list. It seems to me that the "implementation specific environment
415     hacking functions" found in pcl/walker.lisp are completely messed
416     up. The good thing is that they appear to be barely used within
417     PCL and the munged environment object is passed to cmucl only
418     in calls to macroexpand-1, which is probably why this case fails.
419   SBCL uses essentially the same code, so if the environment hacking
420   is screwed up, it affects us too.
421
422 64:
423   Using the pretty-printer from the command prompt gives funny
424   results, apparently because the pretty-printer doesn't know
425   about user's command input, including the user's carriage return
426   that the user, and therefore the pretty-printer thinks that
427   the new output block should start indented 2 or more characters
428   rightward of the correct location.
429
430 65:
431   (probably related to bug #70; maybe related to bug #109)
432   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
433   compiling this file
434 (in-package "CL-USER")
435 (defun equal-terms (termx termy)
436   (labels
437     ((alpha-equal-bound-term-lists (listx listy)
438        (or (and (null listx) (null listy))
439            (and listx listy
440                 (let ((bindings-x (bindings-of-bound-term (car listx)))
441                       (bindings-y (bindings-of-bound-term (car listy))))
442                   (if (and (null bindings-x) (null bindings-y))
443                       (alpha-equal-terms (term-of-bound-term (car listx))
444                                          (term-of-bound-term (car listy)))
445                       (and (= (length bindings-x) (length bindings-y))
446                            (prog2
447                                (enter-binding-pairs (bindings-of-bound-term (car listx))
448                                                     (bindings-of-bound-term (car listy)))
449                                (alpha-equal-terms (term-of-bound-term (car listx))
450                                                   (term-of-bound-term (car listy)))
451                              (exit-binding-pairs (bindings-of-bound-term (car listx))
452                                                  (bindings-of-bound-term (car listy)))))))
453                 (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
454
455      (alpha-equal-terms (termx termy)
456        (if (and (variable-p termx)
457                 (variable-p termy))
458            (equal-bindings (id-of-variable-term termx)
459                            (id-of-variable-term termy))
460            (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
461                 (alpha-equal-bound-term-lists (bound-terms-of-term termx)
462                                               (bound-terms-of-term termy))))))
463
464     (or (eq termx termy)
465         (and termx termy
466              (with-variable-invocation (alpha-equal-terms termx termy))))))
467   causes an assertion failure
468     The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
469                       (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
470
471   Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
472   case with the same problem:
473 (defun parse-fssp-alignment ()
474   ;; Given an FSSP alignment file named by the argument . . .
475   (labels ((get-fssp-char ()
476              (get-fssp-char))
477            (read-fssp-char ()
478              (get-fssp-char)))
479     ;; Stub body, enough to tickle the bug.
480     (list (read-fssp-char)
481           (read-fssp-char))))
482
483 66:
484   ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
485   a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
486     (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
487   This also leads to funny behavior when derived type specifiers
488   are used, as originally reported by Milan Zamazal for CMU CL (on the
489   Debian bugs mailing list (?) 2000-02-27), then reported by Martin
490   Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
491     (DEFTYPE FOO () 'SIMPLE-ARRAY)
492     (CONCATENATE 'FOO #(1 2) '(3)) 
493       => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
494            sequence functions.
495   The derived type specifier FOO should act the same way as the 
496   built-in type SIMPLE-ARRAY here, but it doesn't. That problem
497   doesn't seem to exist for sequence types:
498     (DEFTYPE BAR () 'SIMPLE-VECTOR)
499     (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
500
501 67:
502   As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
503   and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
504   crashes SBCL. In general tracing anything which is used in the 
505   implementation of TRACE is likely to have the same problem.
506
507 68: 
508   As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
509   SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
510   notably including all PCL instances. There's a limit to how much
511   SXHASH can do to return unique values for instances, but at least
512   it should probably look at the class name, the way that it does
513   for STRUCTURE-OBJECTs.
514
515 70:
516   (probably related to bug #65; maybe related to bug #109)
517   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
518   forms. E.g.
519     (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
520       (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
521                  (LET ((ITEM (FIRST SEQ)))
522                    (COND ((NULL SEQ)
523                           (VALUES NIL NIL))
524                          ((FUNCALL TEST OBJ ITEM)
525                           (VALUES VAL SEQ))
526                          (T     
527                           (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
528       (FIND-ITEM ITEM SEQUENCE TEST)))
529   from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
530   causes sbcl-0.6.9 to fail with
531     error in function SB-KERNEL:ASSERT-ERROR:
532        The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
533                          (SB-C::LAMBDA-TAIL-SET
534                           (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
535
536 71: 
537   (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after 
538   (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
539   the previous SPEED policy. This bug will probably get fixed in
540   0.6.9.x in a general cleanup of optimization policy.
541
542 72:
543   (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
544
545 75:
546   As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
547   ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
548   :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
549   WITH-OUTPUT-TO-STRING.
550
551 78:
552   ANSI says in one place that type declarations can be abbreviated even
553   when the type name is not a symbol, e.g.
554     (DECLAIM ((VECTOR T) *FOOVECTOR*))
555   SBCL doesn't support this. But ANSI says in another place that this
556   isn't allowed. So it's not clear this is a bug after all. (See the
557   e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
558   and Pierre Mai.)
559
560 79:
561   as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
562   The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
563   an easily guessable temporary filename in a way which might open
564   applications using LOAD-FOREIGN to hijacking by malicious users
565   on the same machine. Incantations for doing this safely are
566   floating around the net in various "how to write secure programs
567   despite Unix" documents, and it would be good to (1) fix this in 
568   LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
569   files and make it share the same new safe logic.
570
571 82: 
572   Functions are assigned names based on the context in which they're
573   defined. This is less than ideal for the functions which are
574   used to implement CLOS methods. E.g. the output of 
575   (DESCRIBE 'PRINT-OBJECT) lists functions like 
576         #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}> 
577   and
578         #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
579   It would be better if these functions' names always identified
580   them as methods, and identified their generic functions and
581   specializers.
582
583 83:
584   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
585   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
586   the mean of the distribution can be systematically O(0.1%) wrong.
587   Just increasing R-I-E-B is probably not a good solution, since
588   it would decrease efficiency more than is probably necessary. Perhaps
589   using some sort of accept/reject method would be better.
590
591 85:
592   Internally the compiler sometimes evaluates
593     (sb-kernel:type/= (specifier-type '*) (specifier-type t))
594   (I stumbled across this when I added an
595     (assert (not (eq type1 *wild-type*)))
596   in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
597   in a type context should probably be translated to T, and so it's
598   probably wrong to ask whether it's equal to the T type and then (using
599   the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
600   (I haven't tried to investigate this bug enough to guess whether
601   there might be any user-level symptoms.)
602
603 90: 
604   a latent cross-compilation/bootstrapping bug: The cross-compilation
605   host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
606   and possibly elsewhere. Instead, we should use the target system's
607   CHAR-CODE-LIMIT. This will probably cause problems if we try to 
608   bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
609   than SBCL does.
610
611 91:
612   (subtypep '(or (integer -1 1)
613                  unsigned-byte)
614             '(or (rational -1 7)
615                  unsigned-byte
616                  (integer -1 1))) => NIL,T
617   An analogous problem with SINGLE-FLOAT and REAL types was fixed in 
618   sbcl-0.6.11.22, but some peculiarites of the RATIO type make it 
619   awkward to generalize the fix to INTEGER and RATIONAL. It's not 
620   clear what's the best fix. (See the "bug in type handling" discussion
621   on cmucl-imp ca. 2001-03-22 and ca. 2001-02-12.)
622
623 94a: 
624   Inconsistencies between derived and declared VALUES return types for
625   DEFUN aren't checked very well. E.g. the logic which successfully
626   catches problems like
627     (declaim (ftype (function (fixnum) float) foo))
628     (defun foo (x)
629       (declare (type integer x))
630       (values x)) ; wrong return type, detected, gives warning, good!
631   fails to catch
632     (declaim (ftype (function (t) (values t t)) bar))
633     (defun bar (x)
634       (values x)) ; wrong number of return values, no warning, bad!
635   The cause of this is seems to be that (1) the internal function 
636   VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
637   arguments symmetrically, and (2) when the type checking code was
638   written back when when SBCL's code was still CMU CL, the intent
639   was that this case
640     (declaim (ftype (function (t) t) bar))
641     (defun bar (x)
642       (values x x)) ; wrong number of return values; should give warning?
643   not be warned for, because a two-valued return value is considered
644   to be compatible with callers who expects a single value to be
645   returned. That intent is probably not appropriate for modern ANSI
646   Common Lisp, but fixing this might be complicated because of other
647   divergences between auld-style and new-style handling of
648   multiple-VALUES types. (Some issues related to this were discussed
649   on cmucl-imp at some length sometime in 2000.)
650
651 95:
652   The facility for dumping a running Lisp image to disk gets confused
653   when run without the PURIFY option, and creates an unnecessarily large
654   core file (apparently representing memory usage up to the previous
655   high-water mark). Moreover, when the file is loaded, it confuses the
656   GC, so that thereafter memory usage can never be reduced below that
657   level.
658
659 96:
660   The TRACE facility can't be used on some kinds of functions.
661   (Basically, the breakpoint facility was incompletely implemented
662   in the X86 port of CMU CL, and hasn't been fixed in SBCL.)
663
664 98:
665   In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
666   CL), out-of-line structure slot setters are horribly inefficient
667   whenever the type of the slot is declared, because out-of-line
668   structure slot setters are implemented as closures to save space,
669   so the compiler doesn't compile the type test into code, but
670   instead just saves the type in a lexical closure and interprets it
671   at runtime.
672     A proper solution involves deciding whether it's really worth
673   saving space by implementing structure slot accessors as closures.
674   (If it's not worth it, the problem vanishes automatically. If it
675   is worth it, there are hacks we could use to force type tests to
676   be compiled anyway, and even shared. E.g. we could implement
677   an EQUAL hash table mapping from types to compiled type tests, 
678   and save the appropriate compiled type test as part of each lexical
679   closure; or we could make the lexical closures be placeholders
680   which overwrite their old definition as a lexical closure with
681   a new compiled definition the first time that they're called.)
682     As a workaround for the problem, #'(SETF FOO) expressions can
683   be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
684 (defmacro efficient-setf-function (place-function-name)
685   (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
686                   ;; a workaround for the problem, encouraging the
687                   ;; inline expansion of the structure accessor, so
688                   ;; that the compiler can optimize its type test
689                   (let ((new-value (gensym "NEW-VALUE-"))
690                         (structure-value (gensym "STRUCTURE-VALUE-")))
691                     `(lambda (,new-value ,structure-value)
692                        (setf (,place-function-name ,structure-value)
693                              ,new-value))))
694       ;; no problem, can just use the ordinary expansion
695       `(function (setf ,place-function-name))))
696
697 100:
698   There's apparently a bug in CEILING optimization which caused 
699   Douglas Crosher to patch the CMU CL version. Martin Atzmueller
700   applied the patches to SBCL and they didn't seem to cause problems
701   (as reported sbcl-devel 2001-05-04). However, since the patches
702   modify nontrivial code which was apparently written incorrectly
703   the first time around, until regression tests are written I'm not 
704   comfortable merging the patches in the CVS version of SBCL.
705
706 102:
707   As reported by Arthur Lemmens sbcl-devel 2001-05-05, ANSI
708   requires that SYMBOL-MACROLET refuse to rebind special variables,
709   but SBCL doesn't do this. (Also as reported by AL in the same
710   message, SBCL depended on this nonconforming behavior to build
711   itself, because of the way that **CURRENT-SEGMENT** was implemented.
712   As of sbcl-0.6.12.x, this dependence on the nonconforming behavior
713   has been fixed, but the nonconforming behavior remains.)
714
715 104:
716   (DESCRIBE 'SB-ALIEN:DEF-ALIEN-TYPE) reports the macro argument list
717   incorrectly:
718         DEF-ALIEN-TYPE is
719           an external symbol
720           in #<PACKAGE "SB-ALIEN">.
721         Macro-function: #<FUNCTION "DEF!MACRO DEF-ALIEN-TYPE" {19F4A39}>
722           Macro arguments:  (#:whole-470 #:environment-471)
723           On Sat, May 26, 2001 09:45:57 AM CDT it was compiled from:
724           /usr/stuff/sbcl/src/code/host-alieneval.lisp
725             Created: Monday, March 12, 2001 07:47:43 AM CST
726
727 108:
728   (TIME (ROOM T)) reports more than 200 Mbytes consed even for
729   a clean, just-started SBCL system. And it seems to be right:
730   (ROOM T) can bring a small computer to its knees for a *long*
731   time trying to GC afterwards. Surely there's some more economical
732   way to implement (ROOM T).
733
734 109:
735   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
736   collection:
737     ;;; This file fails to compile.
738     ;;; Maybe this bug is related to bugs #65, #70 in the BUGS file.
739     (in-package :cl-user)
740     (defun tst2 ()
741       (labels 
742           ((eff (&key trouble)
743              (eff)
744              ;; nil
745              ;; Uncomment and it works
746              ))
747         (eff)))
748   In SBCL 0.6.12.42, the problem is
749     internal error, failed AVER:
750       "(COMMON-LISP:EQ (SB!C::LAMBDA-TAIL-SET SB!C::CALLER)
751                   (SB!C::LAMBDA-TAIL-SET (SB!C::LAMBDA-HOME SB!C::CALLEE)))"
752
753 110:
754   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
755   collection:
756     ;;; The compiler is flushing the argument type test, and the default
757     ;;; case in the cond, so that calling with say a fixnum 0 causes a
758     ;;; SIGBUS.
759     (declaim (optimize (safety 2) (speed 3)))
760     (defun tst (x)
761       (declare (type (or string stream) x))
762       (cond ((typep x 'string) 'string)
763             ((typep x 'stream) 'stream)
764             (t
765              'none)))
766   The symptom in sbcl-0.6.12.42 on OpenBSD is actually (TST 0)=>STREAM
767   (not the SIGBUS reported in the comment) but that's broken too; 
768   type declarations are supposed to be treated as assertions unless
769   SAFETY 0, so we should be getting a TYPE-ERROR.
770
771 113:
772   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
773   collection:
774     (in-package :cl-user)
775     ;;; From: David Gadbois <gadbois@cyc.com>
776     ;;;
777     ;;; Logical pathnames aren't externalizable.
778     ;;; Test case:
779     (let ((tempfile "/tmp/test.lisp"))
780       (setf (logical-pathname-translations "XXX")
781             '(("XXX:**;*.*" "/tmp/**/*.*")))
782       (with-open-file (out tempfile :direction :output)
783         (write-string "(defvar *path* #P\"XXX:XXX;FOO.LISP\")" out))
784       (compile-file tempfile))
785   The error message in sbcl-0.6.12.42 is
786     ; caught ERROR:
787     ;   (while making load form for #<SB-IMPL::LOGICAL-HOST "XXX">)
788     ; A logical host can't be dumped as a constant: #<SB-IMPL::LOGICAL-HOST "XXX">
789
790 115:
791   reported by Martin Atzmueller 2001-06-25; originally from CMU CL bugs
792   collection:
793     (in-package :cl-user)
794     ;;; The following invokes a compiler error.
795     (declaim (optimize (speed 2) (debug 3)))
796     (defun tst ()
797       (flet ((m1 ()
798                (unwind-protect nil)))
799         (if (catch nil)
800           (m1)
801           (m1))))
802   The error message in sbcl-0.6.12.42 is
803     internal error, failed AVER:
804       "(COMMON-LISP:EQ (SB!C::TN-ENVIRONMENT SB!C:TN) SB!C::TN-ENV)"
805
806 117:
807   When the compiler inline expands functions, it may be that different
808   kinds of return values are generated from different code branches.
809   E.g. an inline expansion of POSITION generates integer results 
810   from one branch, and NIL results from another. When that inline
811   expansion is used in a context where only one of those results
812   is acceptable, e.g.
813     (defun foo (x)
814       (aref *a1* (position x *a2*)))
815   and the compiler can't prove that the unacceptable branch is 
816   never taken, then bogus type mismatch warnings can be generated.
817   If you need to suppress the type mismatch warnings, you can
818   suppress the inline expansion,
819     (defun foo (x)
820       #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
821       (aref *a1* (position x *a2*)))
822   or, sometimes, suppress them by declaring the result to be of an
823   appropriate type,
824     (defun foo (x)
825       (aref *a1* (the integer (position x *a2*))))
826
827   This is not a new compiler problem in 0.7.0, but the new compiler
828   transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it 
829   more conspicuous. If you don't need performance from these functions,
830   and the bogus warnings are a nuisance for you, you can return to
831   your pre-0.7.0 state of grace with
832     #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
833
834 118:
835    as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
836      (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
837         (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
838    when of course it should be NIL. (He says it only fails for X86,
839    not SPARC; dunno about Alpha.)
840
841    Also, "the same problem exists for LONG-FLOAT-EPSILON,
842    DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
843    for the -negative- the + is replaced by a - in the test)."
844
845    Raymond Toy comments that this is tricky on the X86 since its FPU
846    uses 80-bit precision internally.
847
848 120a:
849    The compiler incorrectly figures the return type of 
850         (DEFUN FOO (FRAME UP-FRAME)
851           (IF (OR (NOT FRAME)
852                   T)
853               FRAME
854               "BAR"))
855    as NIL.
856
857    This problem exists in CMU CL 18c too. When I reported it on
858    cmucl-imp@cons.org, Raymond Toy replied 23 Aug 2001 with 
859    a partial explanation, but no fix has been found yet.
860
861 120b:
862    Even in sbcl-0.pre7.x, which is supposed to be free of the old
863    non-ANSI behavior of treating the function return type inferred
864    from the current function definition as a declaration of the
865    return type from any function of that name, the return type of NIL
866    is attached to FOO in 120a above, and used to optimize code which
867    calls FOO. 
868
869 122:
870    There was some sort of screwup in handling of
871    (IF (NOT (IGNORE-ERRORS ..))). E.g.
872         (defun foo1i ()
873           (if (not (ignore-errors
874                      (make-pathname :host "foo" :directory "!bla" :name "bar")))
875               (print "ok")
876               (error "notunlessnot")))
877    The (NOT (IGNORE-ERRORS ..)) form evaluates to T, so this should be
878    printing "ok", but instead it's going to the ERROR. This problem
879    seems to've been introduced by MNA's HANDLER-CASE patch (sbcl-devel
880    2001-07-17) and as a workaround (put in sbcl-0.pre7.14.flaky4.12)
881    I reverted back to the old weird HANDLER-CASE code. However, I
882    think the problem looks like a compiler bug in handling RETURN-FROM,
883    so I left the MNA-patched code in HANDLER-CASE (suppressed with
884    #+NIL) and I'd like to go back to see whether this really is
885    a compiler bug before I delete this BUGS entry.
886
887 123:
888    The *USE-IMPLEMENTATION-TYPES* hack causes bugs, particularly
889      (IN-PACKAGE :SB-KERNEL)
890      (TYPE= (SPECIFIER-TYPE '(VECTOR T))
891             (SPECIFIER-TYPE '(VECTOR UNDEFTYPE)))
892    Then because of this, the compiler bogusly optimizes
893         (TYPEP #(11) '(SIMPLE-ARRAY UNDEF-TYPE 1))
894    to T. Unfortunately, just setting *USE-IMPLEMENTATION-TYPES* to 
895    NIL around sbcl-0.pre7.14.flaky4.12 didn't work: the compiler complained
896    about type mismatches (probably harmlessly, another instance of bug 117);
897    and then cold init died with a segmentation fault.
898
899 124:
900    As of version 0.pre7.14, SBCL's implementation of MACROLET makes
901    the entire lexical environment at the point of MACROLET available
902    in the bodies of the macroexpander functions. In particular, it 
903    allows the function bodies (which run at compile time) to try to 
904    access lexical variables (which are only defined at runtime).
905    It doesn't even issue a warning, which is bad.
906   
907    The SBCL behavior arguably conforms to the ANSI spec (since the
908    spec says that the behavior is undefined, ergo anything conforms).
909    However, it would be better to issue a compile-time error.
910    Unfortunately I (WHN) don't see any simple way to detect this
911    condition in order to issue such an error, so for the meantime
912    SBCL just does this weird broken "conforming" thing.
913
914    The ANSI standard says, in the definition of the special operator
915    MACROLET,
916        The macro-expansion functions defined by MACROLET are defined
917        in the lexical environment in which the MACROLET form appears.
918        Declarations and MACROLET and SYMBOL-MACROLET definitions affect
919        the local macro definitions in a MACROLET, but the consequences
920        are undefined if the local macro definitions reference any
921        local variable or function bindings that are visible in that
922        lexical environment. 
923    Then it seems to contradict itself by giving the example
924         (defun foo (x flag)
925            (macrolet ((fudge (z)
926                          ;The parameters x and flag are not accessible
927                          ; at this point; a reference to flag would be to
928                          ; the global variable of that name.
929                          ` (if flag (* ,z ,z) ,z)))
930             ;The parameters x and flag are accessible here.
931              (+ x
932                 (fudge x)
933                 (fudge (+ x 1)))))
934    The comment "a reference to flag would be to the global variable
935    of the same name" sounds like good behavior for the system to have.
936    but actual specification quoted above says that the actual behavior
937    is undefined.
938
939 125:
940    (as reported by Gabe Garza on cmucl-help 2001-09-21)
941         (defvar *tmp* 3)
942         (defun test-pred (x y)
943           (eq x y))
944         (defun test-case ()
945           (let* ((x *tmp*)
946                  (func (lambda () x)))
947             (print (eq func func))
948             (print (test-pred func func))
949             (delete func (list func))))
950    Now calling (TEST-CASE) gives output
951      NIL
952      NIL
953      (#<FUNCTION {500A9EF9}>)
954    Evidently Python thinks of the lambda as a code transformation so
955    much that it forgets that it's also an object.
956
957 126:
958   (fixed in 0.pre7.41)
959
960 127:
961   The DEFSTRUCT section of the ANSI spec, in the :CONC-NAME section,
962   specifies a precedence rule for name collisions between slot accessors of
963   structure classes related by inheritance. As of 0.7.0, SBCL still 
964   doesn't follow it.
965
966 129:
967   insufficient syntax checking in MACROLET:
968    (defun foo (x)
969      (macrolet ((defmacro bar (z) `(+ z z)))
970        (bar x)))
971   shouldn't compile without error (because of the extra DEFMACRO symbol).
972
973 131:
974   As of sbcl-0.pre7.86.flaky7.3, the cross-compiler, and probably 
975   the CL:COMPILE function (which is based on the same %COMPILE 
976   mechanism) get confused by 
977 (defun sxhash (x)
978   (labels ((sxhash-number (x)
979              (etypecase x
980                (fixnum (sxhash x)) ; through DEFTRANSFORM
981                (integer (sb!bignum:sxhash-bignum x))
982                (single-float (sxhash x)) ; through DEFTRANSFORM
983                (double-float (sxhash x)) ; through DEFTRANSFORM
984                #!+long-float (long-float (error "stub: no LONG-FLOAT"))
985                (ratio (let ((result 127810327))
986                         (declare (type fixnum result))
987                         (mixf result (sxhash-number (numerator x)))
988                         (mixf result (sxhash-number (denominator x)))
989                         result))
990                (complex (let ((result 535698211))
991                           (declare (type fixnum result))
992                           (mixf result (sxhash-number (realpart x)))
993                           (mixf result (sxhash-number (imagpart x)))
994                           result))))
995            (sxhash-recurse (x &optional (depthoid +max-hash-depthoid+))
996              (declare (type index depthoid))
997              (typecase x
998                (list
999                 (if (plusp depthoid)
1000                     (mix (sxhash-recurse (car x) (1- depthoid))
1001                          (sxhash-recurse (cdr x) (1- depthoid)))
1002                     261835505))
1003                (instance
1004                 (if (typep x 'structure-object)
1005                     (logxor 422371266
1006                             (sxhash ; through DEFTRANSFORM
1007                              (class-name (layout-class (%instance-layout x)))))
1008                     309518995))
1009                (symbol (sxhash x)) ; through DEFTRANSFORM
1010                (number (sxhash-number x))
1011                (array
1012                 (typecase x
1013                   (simple-string (sxhash x)) ; through DEFTRANSFORM
1014                   (string (%sxhash-substring x))
1015                   (bit-vector (let ((result 410823708))
1016                                 (declare (type fixnum result))
1017                                 (dotimes (i (min depthoid (length x)))
1018                                   (mixf result (aref x i)))
1019                                 result))
1020                   (t (logxor 191020317 (sxhash (array-rank x))))))
1021                (character
1022                 (logxor 72185131
1023                         (sxhash (char-code x)))) ; through DEFTRANSFORM
1024                (t 42))))
1025     (sxhash-recurse x)))
1026   complaining "function called with two arguments, but wants exactly
1027   one" about SXHASH-RECURSE. (This might not be strictly a new bug, 
1028   since IIRC post-fork CMU CL has also had problems with &OPTIONAL
1029   arguments in FLET/LABELS: it might be an old Python bug which is 
1030   only exercised by the new arrangement of the SBCL compiler.)
1031
1032 135:
1033   Ideally, uninterning a symbol would allow it, and its associated
1034   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However, 
1035   at least as of sbcl-0.7.0, this isn't the case. Information about
1036   FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
1037   essentially in ordinary (non-weak) hash tables keyed by symbols.
1038   Thus, once a system has an entry in this system, it tends to live
1039   forever, even when it is uninterned and all other references to it
1040   are lost. 
1041
1042 136:
1043   (reported by Arnaud Rouanet on cmucl-imp 2001-12-18)
1044     (defmethod foo ((x integer))
1045       x)
1046     (defmethod foo :around ((x integer))
1047       (let ((x (1+ x)))
1048         (call-next-method)))
1049   Now (FOO 3) should return 3, but instead it returns 4.
1050     
1051 137:
1052   (SB-DEBUG:BACKTRACE) output should start with something
1053   including the name BACKTRACE, not (as in 0.pre7.88)
1054   just "0: (\"hairy arg processor\" ...)". Until about
1055   sbcl-0.pre7.109, the names in BACKTRACE were all screwed
1056   up compared to the nice useful names in sbcl-0.6.13.
1057   Around sbcl-0.pre7.109, they were mostly fixed by using
1058   NAMED-LAMBDA to implement DEFUN. However, there are still
1059   some screwups left, e.g. as of sbcl-0.pre7.109, there are
1060   still some functions named "hairy arg processor" and
1061   "SB-INT:&MORE processor".
1062
1063 140:
1064   (reported by Alexey Dejneka sbcl-devel 2002-01-03)
1065
1066   SUBTYPEP does not work well with redefined classes:
1067   ---
1068   * (defclass a () ())
1069   #<STANDARD-CLASS A>
1070   * (defclass b () ())
1071   #<STANDARD-CLASS B>
1072   * (subtypep 'b 'a)
1073   NIL
1074   T
1075   * (defclass b (a) ())
1076   #<STANDARD-CLASS B>
1077   * (subtypep 'b 'a)
1078   T
1079   T
1080   * (defclass b () ())
1081   #<STANDARD-CLASS B>
1082    
1083   ;;; And now...
1084   * (subtypep 'b 'a)
1085   T
1086   T
1087
1088   This is probably due to underzealous clearing of the type caches; a
1089   brute-force solution in that case would be to make a defclass expand
1090   into something that included a call to SB-KERNEL::CLEAR-TYPE-CACHES,
1091   but there may be a better solution.
1092
1093 141: 
1094   Pretty-printing nested backquotes doesn't work right, as 
1095   reported by Alexey Dejneka sbcl-devel 2002-01-13:
1096   * '``(FOO ,@',@S)
1097   ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
1098   * (lisp-implementation-version)
1099   "0.pre7.129"
1100
1101 142:
1102   (as reported by Lynn Quam on cmucl-imp ca. 2002-01-16)
1103   %NATURALIZE-C-STRING conses a lot, like 16 bytes per byte
1104   of the naturalized string. We could probably port the patches
1105   from the cmucl-imp mailing list.
1106
1107 143:
1108   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
1109   prominent SourceForge web/db bug tracking system, which is 
1110   unfortunately not a reliable way to get a timely response from
1111   the SBCL maintainers)
1112       In the course of trying to build a test case for an 
1113     application error, I encountered this behavior: 
1114       If you start up sbcl, and then lay on CTRL-C for a 
1115     minute or two, the lisp process will eventually say: 
1116          %PRIMITIVE HALT called; the party is over. 
1117     and throw you into the monitor. If I start up lisp, 
1118     attach to the process with strace, and then do the same 
1119     (abusive) thing, I get instead: 
1120          access failure in heap page not marked as write-protected 
1121     and the monitor again. I don't know enough to have the 
1122     faintest idea of what is going on here. 
1123       This is with sbcl 6.12, uname -a reports: 
1124          Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown 
1125   I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
1126   under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
1127   it took more than two minutes (but less than five) for me.
1128
1129 144: 
1130   (This was once known as IR1-4, but it lived on even after the
1131   IR1 interpreter went to the big bit bucket in the sky.)
1132   The system accepts DECLAIM in most places where DECLARE would be 
1133   accepted, without even issuing a warning. ANSI allows this, but since
1134   it's fairly easy to mistype DECLAIM instead of DECLARE, and the
1135   meaning is rather different, and it's unlikely that the user
1136   has a good reason for doing DECLAIM not at top level, it would be 
1137   good to issue a STYLE-WARNING when this happens. A possible
1138   fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
1139   or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
1140   [This is considered an IR1-interpreter-related bug because until
1141   EVAL-WHEN is rewritten, which won't happen until after the IR1
1142   interpreter is gone, the system's notion of what's a top-level form
1143   and what's not will remain too confused to fix this problem.]
1144
1145 145:
1146   ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
1147   FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
1148   COMPLEX implementation didn't deal with this, and hasn't been
1149   upgraded to do so. (This doesn't seem to be a high priority
1150   conformance problem, since seems hard to construct useful code
1151   where it matters.)
1152
1153 146:
1154   Floating point errors are reported poorly. E.g. on x86 OpenBSD
1155   with sbcl-0.7.1, 
1156         * (expt 2.0 12777)
1157         debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
1158           An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
1159         No traps are enabled? How can this be?
1160   It should be possible to be much more specific (overflow, division
1161   by zero, etc.) and of course the "How can this be?" should be fixable.
1162
1163 147:
1164   (reported by Alexey Dejneka sbcl-devel 2002-01-28)
1165   Compiling a file containing
1166     (deftype digit () '(member #\1))
1167     (defun parse-num (string ind)
1168       (flet ((digs ()
1169                (let (old-index)
1170                  (if (and (< ind ind)
1171                           (typep (char string ind) 'digit))
1172                      nil))))))
1173   in sbcl-0.7.1 causes the compiler to fail with
1174     internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
1175   This problem seems to have been introduced by the sbcl-0.pre7.* compiler
1176   changes, since 0.pre7.73 and 0.6.13 don't suffer from it. A related
1177   test case is
1178     (defun parse-num (index)
1179       (let (num x)
1180         (flet ((digs ()
1181                  (setq num index))
1182                (z ()
1183                  (let ()
1184                    (setq x nil))))
1185           (when (and (digs) (digs)) x))))
1186   In sbcl-0.7.1, this second test case failed with the same
1187     internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
1188   After the APD patches in sbcl-0.7.1.2 (new consistency check in
1189   TARGET-IF-DESIRABLE, plus a fix in meta-vmdef.lisp to keep the
1190   new consistency check from failing routinely) this second test case
1191   failed in FIND-IN-PHYSENV instead. Fixes in sbcl-0.7.1.3 (not
1192   closing over unreferenced variables) made this second test case
1193   compile without error, but the original test case still fails.
1194  
1195   Another way to get rid of the DEFTYPE without changing the symptom
1196   of the bug is
1197     (defvar *ch*)
1198     (defun parse-num (string ind)
1199       (flet ((digs ()
1200                (let ()
1201                  (if (and (< ind ind)
1202                           (sb-int:memq *ch* '(#\1)))
1203                      nil))))))
1204   In sbcl-0.7.1.3, this fails with
1205     internal error, failed AVER: "(= (LENGTH (BLOCK-SUCC CALL-BLOCK)) 1)" 
1206   The problem occurs while the inline expansion of MEMQ,
1207   #<LAMBDA :%DEBUG-NAME "varargs entry point for SB-C::.ANONYMOUS.">
1208   is being LET-converted after having its second REF deleted, leaving
1209   it with only one entry in LEAF-REFS.
1210   
1211 148:
1212   In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
1213     (in-package :cl-user)
1214     (defvar *thing*)
1215     (defvar *zoom*)
1216     (defstruct foo bar bletch)
1217     (defun %zeep ()
1218       (labels ((kidify1 (kid)
1219                  )
1220                (kid-frob (kid)
1221                  (if *thing*
1222                     (setf sweptm
1223                            (m+ (frobnicate kid)
1224                                      sweptm))
1225                     (kidify1 kid))))
1226       (declare (inline kid-frob))
1227       (map nil
1228            #'kid-frob
1229            (the simple-vector (foo-bar perd)))))
1230   fails with
1231     debugger invoked on condition of type TYPE-ERROR:
1232       The value NIL is not of type SB-C::NODE.
1233   The location of this failure has moved around as various related
1234   issues were cleaned up. As of sbcl-0.7.1.9, it occurs in 
1235   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
1236
1237 151:
1238   From the ANSI description of GET-DISPATCH-MACRO-CHARACTER, it
1239   should return NIL when there is no definition, e.g.
1240     (GET-DISPATCH-MACRO-CHARACTER #\# #\{) => NIL
1241   Instead, in sbcl-0.7.1.17 it returns
1242     #<FUNCTION "top level local call SB!IMPL::DISPATCH-CHAR-ERROR">
1243
1244 153:
1245   (essentially the same problem as a CMU CL bug reported by Martin
1246   Cracauer on cmucl-imp 2002-02-19)
1247   There is a hole in structure slot type checking. Compiling and LOADing
1248     (declaim (optimize safety))
1249     (defstruct foo
1250       (bla 0 :type fixnum))
1251     (defun f ()
1252       (let ((foo (make-foo)))
1253         (setf (foo-bla foo) '(1 . 1))
1254         (format t "Is ~a of type ~a a cons? => ~a~%"
1255                 (foo-bla foo)
1256                 (type-of (foo-bla foo))
1257                 (consp (foo-bla foo)))))
1258     (f)
1259   should signal an error, but in sbcl-0.7.1.21 instead gives the output
1260     Is (1 . 1) of type CONS a cons? => NIL
1261   without signalling an error.
1262
1263 154:
1264   There's some sort of problem with aborting back out of the debugger
1265   after a %DETECT-STACK-EXHAUSTION error in sbcl-0.7.1.38. In some cases
1266   telling the debugger to ABORT doesn't get you back to the main REPL,
1267   but instead just gives you another stack exhaustion error. The problem
1268   doesn't occur in the trivial case
1269     * (defun frob () (frob) (frob))
1270     FROB
1271     * (frob)
1272   but it has happened in more complicated cases (which I haven't
1273   figured out how to reproduce).
1274
1275 155:
1276   Executing 
1277     (defclass standard-gadget (basic-gadget) ())
1278     (defclass basic-gadget () ())
1279   gives an error:
1280     The slot SB-PCL::DIRECT-SUPERCLASSES is unbound in the
1281     object #<SB-PCL::STANDARD-CLASS "unbound">.
1282   (reported by Brian Spilsbury sbcl-devel 2002-04-09)
1283
1284 DEFUNCT CATEGORIES OF BUGS
1285   IR1-#:
1286     These labels were used for bugs related to the old IR1 interpreter.
1287     The # values reached 6 before the category was closed down.