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