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