0.6.11.24:
[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. ANSI justifies this specification by saying 
54     The restriction against issuing a warning for type mismatches
55     between a slot-initform and the corresponding slot's :TYPE
56     option is necessary because a slot-initform must be specified
57     in order to specify slot options; in some cases, no suitable
58     default may exist.
59   In SBCL, as in CMU CL (or, for that matter, any compiler which
60   really understands Common Lisp types) a suitable default does
61   exist, in all cases, because the compiler understands the concept
62   of functions which never return (i.e. has return type NIL, e.g.
63   ERROR). Thus, as a portable workaround, you can use a call to
64   some known-never-to-return function as the default. E.g.
65     (DEFSTRUCT FOO
66       (BAR (ERROR "missing :BAR argument")
67            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
68   or 
69     (DECLAIM (FTYPE () NIL) MISSING-ARG) 
70     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
71       (ERROR "missing required argument")) 
72     (DEFSTRUCT FOO
73       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
74       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
75       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
76   Such code will compile without complaint and work correctly either
77   on SBCL or on a completely compliant Common Lisp system.
78
79 6:
80   bogus warnings about undefined functions for magic functions like
81   SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
82   like src/code/float.lisp. Fixing this will probably require
83   straightening out enough bootstrap consistency issues that
84   the cross-compiler can run with *TYPE-SYSTEM-INITIALIZED*.
85   Instead, the cross-compiler runs in a slightly flaky state
86   which is sane enough to compile SBCL itself, but which is
87   also unstable in several ways, including its inability
88   to really grok function declarations.
89
90 7:
91   The "byte compiling top-level form:" output ought to be condensed.
92   Perhaps any number of such consecutive lines ought to turn into a
93   single "byte compiling top-level forms:" line.
94
95 10:
96   The way that the compiler munges types with arguments together
97   with types with no arguments (in e.g. TYPE-EXPAND) leads to
98   weirdness visible to the user:
99         (DEFTYPE FOO () 'FIXNUM)
100         (TYPEP 11 'FOO) => T
101         (TYPEP 11 '(FOO)) => T, which seems weird
102         (TYPEP 11 'FIXNUM) => T
103         (TYPEP 11 '(FIXNUM)) signals an error, as it should
104   The situation is complicated by the presence of Common Lisp types
105   like UNSIGNED-BYTE (which can either be used in list form or alone)
106   so I'm not 100% sure that the behavior above is actually illegal.
107   But I'm 90+% sure, and the following related behavior,
108         (TYPEP 11 'AND) => T
109   treating the bare symbol AND as equivalent to '(AND), is specifically
110   forbidden (by the ANSI specification of the AND type).
111
112 11:
113   It would be nice if the
114         caught ERROR:
115           (during macroexpansion)
116   said what macroexpansion was at fault, e.g.
117         caught ERROR:
118           (during macroexpansion of IN-PACKAGE,
119           during macroexpansion of DEFFOO)
120
121 14:
122   The ANSI syntax for non-STANDARD method combination types in CLOS is
123         (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
124         (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
125   If you mess this up, omitting the PROGN qualifier in in DEFMETHOD,
126         (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
127         (DEFMETHOD FOO ((X BAR)) (PRINT 'NUMBER))
128   the error mesage is not easy to understand:
129            INVALID-METHOD-ERROR was called outside the dynamic scope
130         of a method combination function (inside the body of
131         DEFINE-METHOD-COMBINATION or a method on the generic
132         function COMPUTE-EFFECTIVE-METHOD).
133   It would be better if it were more informative, a la
134            The method combination type for this method (STANDARD) does
135         not match the method combination type for the generic function
136         (PROGN).
137   Also, after you make the mistake of omitting the PROGN qualifier
138   on a DEFMETHOD, doing a new DEFMETHOD with the correct qualifier
139   no longer works:
140         (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
141   gives
142            INVALID-METHOD-ERROR was called outside the dynamic scope
143         of a method combination function (inside the body of
144         DEFINE-METHOD-COMBINATION or a method on the generic
145         function COMPUTE-EFFECTIVE-METHOD).
146   This is not very helpful..
147
148 15:
149   (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
150             '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
151   (Also, when this is fixed, we can enable the code in PROCLAIM which 
152   checks for incompatible FTYPE redeclarations.)
153
154 18:
155   from DTC on the CMU CL mailing list 25 Feb 2000:
156 ;;; Compiler fails when this file is compiled.
157 ;;;
158 ;;; Problem shows up in delete-block within ir1util.lisp. The assertion
159 ;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
160 ;;; fails within bind node branch.
161 ;;;
162 ;;; Note that if c::*check-consistency* is enabled then an un-reached
163 ;;; entry is also reported.
164 ;;;
165 (defun foo (val)
166   (declare (values nil))
167   nil)
168 (defun bug (val)
169   (multiple-value-call
170       #'(lambda (res)
171           (block nil
172             (tagbody
173              loop
174                (when res
175                  (return nil))
176                (go loop))))
177     (foo val))
178   (catch 'ccc1
179     (throw 'ccc1
180       (block bbbb
181         (tagbody
182
183            (let ((ttt #'(lambda () (go cccc))))
184              (declare (special ttt))
185              (return-from bbbb nil))
186
187          cccc
188            (return-from bbbb nil))))))
189
190 19:
191   (I *think* this is a bug. It certainly seems like strange behavior. But
192   the ANSI spec is scary, dark, and deep..)
193     (FORMAT NIL  "~,1G" 1.4) => "1.    "
194     (FORMAT NIL "~3,1G" 1.4) => "1.    "
195
196 20:
197   from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
198         (defclass ccc () ())
199         (setf (find-class 'ccc1) (find-class 'ccc))
200         (defmethod zut ((c ccc1)) 123)
201   DTC's recommended workaround from the mailing list 3 Mar 2000:
202         (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
203
204 22:
205   The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
206   says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
207   inside "~<..~>" (without the colon modifier on the closing syntax).
208   However, SBCL doesn't do this:
209         * (FORMAT T "~<munge~wegnum~>" 12)
210         munge12egnum
211         NIL
212
213 23:
214   When too many files are opened, OPEN will fail with an
215   uninformative error message 
216         error in function OPEN: error opening #P"/tmp/foo.lisp": NIL
217   instead of saying that too many files are open.
218
219 24:
220   Right now, when COMPILE-FILE has a read error, it actually pops
221   you into the debugger before giving up on the file. It should
222   instead handle the error, perhaps issuing (and handling)
223   a secondary error "caught ERROR: unrecoverable error during compilation"
224   and then return with FAILURE-P true,
225
226 26:
227   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
228
229 Also, there is another bug: `array-displacement' should return an array
230 or nil as first value (as per ANSI CL), while CMUCL declares it as
231 returning an array as first value always.
232
233 27:
234   Sometimes (SB-EXT:QUIT) fails with 
235         Argh! maximum interrupt nesting depth (4096) exceeded, exiting
236         Process inferior-lisp exited abnormally with code 1
237   I haven't noticed a repeatable case of this yet.
238
239 29:
240   some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
241     (DEFUN BAR? (X)
242       (OR (NAR? X)
243           (BLOCK USED-BY-SOME-Y?
244             (FLET ((FROB (STK)
245                      (DOLIST (Y STK)
246                        (UNLESS (REJECTED? Y)
247                          (RETURN-FROM USED-BY-SOME-Y? T)))))
248               (DECLARE (INLINE FROB))
249               (FROB (RSTK X))
250               (FROB (MRSTK X)))
251             NIL)))
252   gives
253    error in function SB-KERNEL:ASSERT-ERROR:
254    The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
255   This is still present in sbcl-0.6.8.
256
257 31:
258   In some cases the compiler believes type declarations on array
259   elements without checking them, e.g.
260         (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1)))
261         (DEFSTRUCT FOO A B)
262         (DEFUN BAR (X)
263           (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X))
264           (WHEN (CONSP (AREF X 0))
265             (PRINT (AREF X 0))))
266         (BAR (VECTOR (MAKE-FOO :A 11 :B 12)))
267   prints
268         #S(FOO :A 11 :B 12) 
269   in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for
270   all cases, e.g. the type assumption *is* checked if the array
271   elements are declared to be of some structure type instead of CONS.
272
273 32:
274   The printer doesn't report closures very well. This is true in 
275   CMU CL 18b as well:
276     (PRINT #'CLASS-NAME)
277   gives
278     #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
279   It would be nice to make closures have a settable name slot,
280   and make things like DEFSTRUCT and FLET, which create closures,
281   set helpful values into this slot.
282
283 33:
284   And as long as we're wishing, it would be awfully nice if INSPECT could
285   also report on closures, telling about the values of the bound variables.
286
287 35:
288   The compiler assumes that any time a function of declared FTYPE
289   doesn't signal an error, its arguments were of the declared type.
290   E.g. compiling and loading
291     (DECLAIM (OPTIMIZE (SAFETY 3)))
292     (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
293     (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL)))
294     (DEFUN FOO (X)
295       (COND ((> (FACTORIAL X) 1.0E6)
296              (FORMAT T "too big~%"))
297             ((INTEGERP X)
298              (FORMAT T "exactly ~S~%" (FACTORIAL X)))
299             (T
300              (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
301   then executing
302     (FOO 1.5)
303   will cause the INTEGERP case to be selected, giving bogus output a la
304     exactly 1.33..
305   This violates the "declarations are assertions" principle.
306   According to the ANSI spec, in the section "System Class FUNCTION",
307   this is a case of "lying to the compiler", but the lying is done
308   by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
309   not by the unexpectedly general definition of FACTORIAL. In any case,
310   "declarations are assertions" means that lying to the compiler should
311   cause an error to be signalled, and should not cause a bogus
312   result to be returned. Thus, the compiler should not assume
313   that arbitrary functions check their argument types. (It might
314   make sense to add another flag (CHECKED?) to DEFKNOWN to 
315   identify functions which *do* check their argument types.)
316
317 38:
318   DEFMETHOD doesn't check the syntax of &REST argument lists properly,
319   accepting &REST even when it's not followed by an argument name:
320         (DEFMETHOD FOO ((X T) &REST) NIL)
321
322 41:
323   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
324         (DEFTYPE INDEXOID () '(INTEGER 0 1000))
325         (DEFUN FOO (X)
326           (DECLARE (TYPE INDEXOID X))
327           (THE (VALUES INDEXOID)
328             (VALUES X)))
329   where the implementation of the type check in function FOO 
330   includes a full call to %TYPEP. There are also some fundamental problems
331   with the interpretation of VALUES types (inherited from CMU CL, and
332   from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
333   mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
334
335 42:
336   The definitions of SIGCONTEXT-FLOAT-REGISTER and
337   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
338   supported on FreeBSD because the floating point state is not saved,
339   but at least as of FreeBSD 4.0, the floating point state *is* saved,
340   so they could be supported after all. Very likely 
341   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
342
343 43:
344   (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. 
345   Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
346   issue with 'union, 'and, 'or etc. So even though according to the
347   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
348   (and now SBCL) interpret them as legal types.
349
350 44:
351   ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
352   CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
353   list, and it is probably possible to use substantially the same 
354   patches to add it to SBCL.
355
356 45:
357   a slew of floating-point-related errors reported by Peter Van Eynde
358   on July 25, 2000:
359         a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
360            Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
361            aren't found.
362         b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and 
363            should probably be 1.4012985e-45. In SBCL,
364            (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
365            than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
366            exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
367            and LEAST-NEGATIVE-LONG-FLOAT.
368         c: Many expressions generate floating infinity:
369                 (/ 1 0.0)
370                 (/ 1 0.0d0)
371                 (EXPT 10.0 1000)
372                 (EXPT 10.0d0 1000)
373            PVE's regression tests want them to raise errors. SBCL
374            generates the infinities instead, which may or may not be
375            conforming behavior, but then blow it by being unable to
376            output the infinities, since support for infinities is generally
377            broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
378            undefined.
379         d: (in section12.erg) various forms a la 
380                 (FLOAT 1 DOUBLE-FLOAT-EPSILON)
381            don't give the right behavior.
382
383 46:
384   type safety errors reported by Peter Van Eynde July 25, 2000:
385         a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
386            => #(A B C)
387            In general lengths of array type specifications aren't
388            checked by COERCE, so it fails when the spec is
389            (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
390         b: CONCATENATE has the same problem of not checking the length
391            of specified output array types. MAKE-SEQUENCE and MAP and
392            MERGE also have the same problem.
393         c: (COERCE 'AND 'FUNCTION) returns something related to
394            (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
395         d: ELT signals SIMPLE-ERROR if its index argument
396            isn't a valid index for its sequence argument, but should 
397            signal TYPE-ERROR instead.
398         e: FILE-LENGTH is supposed to signal a type error when its
399            argument is not a stream associated with a file, but doesn't.
400         f: (FLOAT-RADIX 2/3) should signal an error instead of 
401            returning 2.
402         g: (LOAD "*.lsp") should signal FILE-ERROR.
403         h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
404            should signal TYPE-ERROR.
405         i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
406            be used for input and output as needed. It should fail with
407            TYPE-ERROR when handed e.g. the results of
408            MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
409            the inappropriate positions, but doesn't.
410         j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
411                             (QUOTE STRING)))
412            should probably signal an error instead of making a pathname with
413            a null byte in it.
414         k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
415            not a binary input stream, but instead cheerfully reads from
416            character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
417
418 47:
419   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
420         a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
421            doesn't.
422         b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
423            signal a PROGRAM-ERROR, and doesn't.
424         c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
425            and other DEFCLASS forms with duplicate specifications in their
426            slots, should signal a PROGRAM-ERROR, and doesn't.
427         d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
428            causes a COMPILER-ERROR.
429
430 48:
431   SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
432         a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal
433            PROGRAM-ERROR, but SBCL accepts it instead.
434         b: SYMBOL-MACROLET should refuse to bind something which is
435            declared as a global variable, signalling PROGRAM-ERROR.
436         c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
437            it binds is declared SPECIAL inside.
438
439 49:
440   LOOP bugs reported by Peter Van Eynde July 25, 2000:
441         a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
442            the definition of WITH clauses given in the ANSI spec, but
443            compiles and runs happily in SBCL.
444         b: a messy one involving package iteration:
445 interpreted Form: (LET ((PACKAGE (MAKE-PACKAGE "LOOP-TEST"))) (INTERN "blah" PACKAGE) (LET ((BLAH2 (INTERN "blah2" PACKAGE))) (EXPORT BLAH2 PACKAGE)) (LIST (SORT (LOOP FOR SYM BEING EACH PRESENT-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<)) (SORT (LOOP FOR SYM BEING EACH EXTERNAL-SYMBOL OF PACKAGE FOR SYM-NAME = (SYMBOL-NAME SYM) COLLECT SYM-NAME) (FUNCTION STRING<))))
446 Should be: (("blah" "blah2") ("blah2"))
447 SBCL: (("blah") ("blah2"))
448         * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
449           doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
450
451 50:
452   type system errors reported by Peter Van Eynde July 25, 2000:
453         a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
454            but should be (VALUES T T) instead.
455         b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL
456            but should be (VALUES T T) instead.
457         c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
458         d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
459            blows up at the level of SPECIFIER-TYPE with
460            "Lower bound (0) is greater than upper bound (0)." Probably
461            SPECIFIER-TYPE should return NIL instead.
462         e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
463            "Component type for Complex is not numeric: (EQL 0)."
464            This might be easy to fix; the type system already knows
465            that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
466         f: The type system doesn't know about the condition system,
467            so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL.
468         g: The type system isn't all that smart about relationships
469            between hairy types, as shown in the type.erg test results,
470            e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
471
472 51:
473   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
474         a: (PROGN
475             (DEFGENERIC FOO02 (X))
476             (DEFMETHOD FOO02 ((X NUMBER)) T)
477             (LET ((M (FIND-METHOD (FUNCTION FOO02)
478                                   NIL
479                                   (LIST (FIND-CLASS (QUOTE NUMBER))))))
480               (REMOVE-METHOD (FUNCTION FOO02) M)
481               (DEFGENERIC FOO03 (X))
482               (ADD-METHOD (FUNCTION FOO03) M)))
483            should give an error, but SBCL allows it.
484         b: READ should probably return READER-ERROR, not the bare 
485            arithmetic error, when input a la "1/0" or "1e1000" causes
486            an arithmetic error.
487
488 52:
489   It has been reported (e.g. by Peter Van Eynde) that there are 
490   several metaobject protocol "errors". (In order to fix them, we might
491   need to document exactly what metaobject protocol specification
492   we're following -- the current code is just inherited from PCL.)
493
494 53:
495   another error from Peter Van Eynde 5 September 2000:
496   (FORMAT NIL "~F" "FOO") should work, but instead reports an error.
497   PVE submitted a patch to deal with this bug, but it exposes other
498   comparably serious bugs, so I didn't apply it. It looks as though
499   the FORMAT code needs a fair amount of rewriting in order to comply
500   with the various details of the ANSI spec.
501
502 54:
503   The implementation of #'+ returns its single argument without
504   type checking, e.g. (+ "illegal") => "illegal".
505
506 55:
507   In sbcl-0.6.7, there is no doc string for CL:PUSH, probably 
508   because it's defined with the DEFMACRO-MUNDANELY macro and something
509   is wrong with doc string setting in that macro.
510
511 56:
512   Attempting to use COMPILE on something defined by DEFMACRO fails:
513         (DEFMACRO FOO (X) (CONS X X))
514         (COMPILE 'FOO)
515 Error in function C::GET-LAMBDA-TO-COMPILE:
516    #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
517
518 58:
519   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH) => NIL, NIL
520   Note: I looked into fixing this in 0.6.11.15, but gave up. The
521   problem seems to be that there are two relevant type methods for
522   the subtypep operation, HAIRY :COMPLEX-SUBTYPEP-ARG2 and
523   INTERSECTION :COMPLEX-SUBTYPEP-ARG1, and only the first is
524   called. This could be fixed, but type dispatch is messy and
525   confusing enough already, I don't want to complicate it further.
526   Perhaps someday we can make CLOS cross-compiled (instead of compiled
527   after bootstrapping) so that we don't need to have the type system
528   available before CLOS, and then we can rewrite the type methods to
529   CLOS methods, and then expressing the solutions to stuff like this
530   should become much more straightforward. -- WHN 2001-03-14
531
532 59:
533   CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
534   current working directory). And there's no supported way to update
535   or query the current working directory (a la Unix "chdir" and "pwd"),
536   which is functionality that ILISP needs (and currently gets with low-level
537   hacks).
538
539 60:
540   The debugger LIST-LOCATIONS command doesn't work properly.
541
542 61:
543   Compiling and loading
544     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
545     (FAIL 12)
546   then requesting a BACKTRACE at the debugger prompt gives no information
547   about where in the user program the problem occurred.
548
549 62:
550   The compiler is supposed to do type inference well enough that 
551   the declaration in
552     (TYPECASE X
553       ((SIMPLE-ARRAY SINGLE-FLOAT)
554        (LOCALLY
555          (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
556          ..))
557       ..)
558   is redundant. However, as reported by Juan Jose Garcia Ripoll for
559   CMU CL, it sometimes doesn't. Adding declarations is a pretty good
560   workaround for the problem for now, but can't be done by the TYPECASE
561   macros themselves, since it's too hard for the macro to detect
562   assignments to the variable within the clause. 
563     Note: The compiler *is* smart enough to do the type inference in
564   many cases. This case, derived from a couple of MACROEXPAND-1
565   calls on Ripoll's original test case,
566     (DEFUN NEGMAT (A)
567       (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
568       (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
569              (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
570                (LET ((I 0) (G2554 LENGTH))
571                  (DECLARE (TYPE REAL G2554) (TYPE REAL I))
572                  (TAGBODY
573                   SB-LOOP::NEXT-LOOP
574                   (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
575                   (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
576                   (GO SB-LOOP::NEXT-LOOP)
577                   SB-LOOP::END-LOOP))))))
578   demonstrates the problem; but the problem goes away if the TAGBODY
579   and GO forms are removed (leaving the SETF in ordinary, non-looping
580   code), or if the TAGBODY and GO forms are retained, but the 
581   assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
582
583 63:
584   Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
585     I am looking into this problem that showed up on the cmucl-help
586     list. It seems to me that the "implementation specific environment
587     hacking functions" found in pcl/walker.lisp are completely messed
588     up. The good thing is that they appear to be barely used within
589     PCL and the munged environment object is passed to cmucl only
590     in calls to macroexpand-1, which is probably why this case fails.
591   SBCL uses essentially the same code, so if the environment hacking
592   is screwed up, it affects us too.
593
594 64:
595   Using the pretty-printer from the command prompt gives funny
596   results, apparently because the pretty-printer doesn't know
597   about user's command input, including the user's carriage return
598   that the user, and therefore the pretty-printer thinks that
599   the new output block should start indented 2 or more characters
600   rightward of the correct location.
601
602 65:
603   (probably related to bug #70)
604   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
605   compiling this file
606 (in-package "CL-USER")
607 (defun equal-terms (termx termy)
608   (labels
609     ((alpha-equal-bound-term-lists (listx listy)
610        (or (and (null listx) (null listy))
611            (and listx listy
612                 (let ((bindings-x (bindings-of-bound-term (car listx)))
613                       (bindings-y (bindings-of-bound-term (car listy))))
614                   (if (and (null bindings-x) (null bindings-y))
615                       (alpha-equal-terms (term-of-bound-term (car listx))
616                                          (term-of-bound-term (car listy)))
617                       (and (= (length bindings-x) (length bindings-y))
618                            (prog2
619                                (enter-binding-pairs (bindings-of-bound-term (car listx))
620                                                     (bindings-of-bound-term (car listy)))
621                                (alpha-equal-terms (term-of-bound-term (car listx))
622                                                   (term-of-bound-term (car listy)))
623                              (exit-binding-pairs (bindings-of-bound-term (car listx))
624                                                  (bindings-of-bound-term (car listy)))))))
625                 (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
626
627      (alpha-equal-terms (termx termy)
628        (if (and (variable-p termx)
629                 (variable-p termy))
630            (equal-bindings (id-of-variable-term termx)
631                            (id-of-variable-term termy))
632            (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
633                 (alpha-equal-bound-term-lists (bound-terms-of-term termx)
634                                               (bound-terms-of-term termy))))))
635
636     (or (eq termx termy)
637         (and termx termy
638              (with-variable-invocation (alpha-equal-terms termx termy))))))
639   causes an assertion failure
640     The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
641                       (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
642
643   Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
644   case with the same problem:
645 (defun parse-fssp-alignment ()
646   ;; Given an FSSP alignment file named by the argument . . .
647   (labels ((get-fssp-char ()
648              (get-fssp-char))
649            (read-fssp-char ()
650              (get-fssp-char)))
651     ;; Stub body, enough to tickle the bug.
652     (list (read-fssp-char)
653           (read-fssp-char))))
654
655 66:
656   ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
657   a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
658     (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
659   This also leads to funny behavior when derived type specifiers
660   are used, as originally reported by Milan Zamazal for CMU CL (on the
661   Debian bugs mailing list (?) 2000-02-27), then reported by Martin
662   Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
663     (DEFTYPE FOO () 'SIMPLE-ARRAY)
664     (CONCATENATE 'FOO #(1 2) '(3)) 
665       => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
666            sequence functions.
667   The derived type specifier FOO should act the same way as the 
668   built-in type SIMPLE-ARRAY here, but it doesn't. That problem
669   doesn't seem to exist for sequence types:
670     (DEFTYPE BAR () 'SIMPLE-VECTOR)
671     (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
672
673 67:
674   As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
675   and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
676   crashes SBCL. In general tracing anything which is used in the 
677   implementation of TRACE is likely to have the same problem.
678
679 68: 
680   As reported by Daniel Solaz on cmucl-help@cons.org 2000-11-23,
681   SXHASH returns the same value for all non-STRUCTURE-OBJECT instances,
682   notably including all PCL instances. There's a limit to how much
683   SXHASH can do to return unique values for instances, but at least
684   it should probably look at the class name, the way that it does
685   for STRUCTURE-OBJECTs.
686
687 69:
688   As reported by Martin Atzmueller on the sbcl-devel list 2000-11-22,
689   > There remains one issue, that is a bug in SBCL:
690   > According to my interpretation of the spec, the ":" and "@" modifiers
691   > should appear _after_ the comma-seperated arguments.
692   > Well, SBCL (and CMUCL for that matter) accept 
693   > (ASSERT (STRING= (FORMAT NIL "~:8D" 1) "   1"))
694   > where the correct way (IMHO) should be
695   > (ASSERT (STRING= (FORMAT NIL "~8:D" 1) "   1"))
696   Probably SBCL should stop accepting the "~:8D"-style format arguments,
697   or at least issue a warning.
698
699 70:
700   (probably related to bug #65)
701   The compiler doesn't like &OPTIONAL arguments in LABELS and FLET
702   forms. E.g.
703     (DEFUN FIND-BEFORE (ITEM SEQUENCE &KEY (TEST #'EQL))
704       (LABELS ((FIND-ITEM (OBJ SEQ TEST &OPTIONAL (VAL NIL))
705                  (LET ((ITEM (FIRST SEQ)))
706                    (COND ((NULL SEQ)
707                           (VALUES NIL NIL))
708                          ((FUNCALL TEST OBJ ITEM)
709                           (VALUES VAL SEQ))
710                          (T     
711                           (FIND-ITEM OBJ (REST SEQ) TEST (NCONC VAL `(,ITEM))))))))
712       (FIND-ITEM ITEM SEQUENCE TEST)))
713   from David Young's bug report on cmucl-help@cons.org 30 Nov 2000
714   causes sbcl-0.6.9 to fail with
715     error in function SB-KERNEL:ASSERT-ERROR:
716        The assertion (EQ (SB-C::LAMBDA-TAIL-SET SB-C::CALLER)
717                          (SB-C::LAMBDA-TAIL-SET
718                           (SB-C::LAMBDA-HOME SB-C::CALLEE))) failed.
719
720 71: 
721   (DECLAIM (OPTIMIZE ..)) doesn't work. E.g. even after 
722   (DECLAIM (OPTIMIZE (SPEED 3))), things are still optimized with
723   the previous SPEED policy. This bug will probably get fixed in
724   0.6.9.x in a general cleanup of optimization policy.
725
726 72:
727   (DECLAIM (OPTIMIZE ..)) doesn't work properly inside LOCALLY forms.
728
729 74:
730   As noted in the ANSI specification for COERCE, (COERCE 3 'COMPLEX)
731   gives a result which isn't COMPLEX. The result type optimizer
732   for COERCE doesn't know this, perhaps because it was written before
733   ANSI threw this curveball: the optimizer thinks that COERCE always
734   returns a result of the specified type. Thus while the interpreted
735   function
736      (DEFUN TRICKY (X) (TYPEP (COERCE X 'COMPLEX) 'COMPLEX))
737   returns the correct result,
738      (TRICKY 3) => NIL
739   the compiled function
740      (COMPILE 'TRICKY)
741   does not:
742      (TRICKY 3) => T
743
744 75:
745   As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
746   ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
747   :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
748   WITH-OUTPUT-TO-STRING.
749
750 78:
751   ANSI says in one place that type declarations can be abbreviated even
752   when the type name is not a symbol, e.g.
753     (DECLAIM ((VECTOR T) *FOOVECTOR*))
754   SBCL doesn't support this. But ANSI says in another place that this
755   isn't allowed. So it's not clear this is a bug after all. (See the
756   e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
757   and Pierre Mai.)
758
759 79:
760   as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
761   The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
762   an easily guessable temporary filename in a way which might open
763   applications using LOAD-FOREIGN to hijacking by malicious users
764   on the same machine. Incantations for doing this safely are
765   floating around the net in various "how to write secure programs
766   despite Unix" documents, and it would be good to (1) fix this in 
767   LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
768   files and make it share the same new safe logic.
769
770 80:
771   (fixed early Feb 2001 by MNA)
772
773 81:
774   As reported by wbuss@TELDA.NET (Wolfhard Buss) on cmucl-help
775   2001-02-14, 
776     According to CLHS
777          (loop with (a . b) of-type float = '(0.0 . 1.0)
778            and (c . d) of-type float = '(2.0 . 3.0)
779            return (list a b c d))
780     should evaluate to (0.0 1.0 2.0 3.0). cmucl-18c disagrees and
781     invokes the debugger: "B is not of type list".
782   SBCL does the same thing.
783
784 82: 
785   Functions are assigned names based on the context in which they're
786   defined. This is less than ideal for the functions which are
787   used to implement CLOS methods. E.g. the output of 
788   (DESCRIBE 'PRINT-OBJECT) lists functions like 
789         #<FUNCTION "DEF!STRUCT (TRACE-INFO (:MAKE-LOAD-FORM-FUN SB-KERNEL:JUST-DUMP-IT-NORMALLY) (:PRINT-OBJECT #))" {1020E49}> 
790   and
791         #<FUNCTION "MACROLET ((FORCE-DELAYED-DEF!METHODS NIL #))" {1242871}>
792   It would be better if these functions' names always identified
793   them as methods, and identified their generic functions and
794   specializers.
795
796 83:
797   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
798   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
799   the mean of the distribution can be systematically O(0.1%) wrong.
800   Just increasing R-I-E-B is probably not a good solution, since
801   it would decrease efficiency more than is probably necessary. Perhaps
802   using some sort of accept/reject method would be better.
803
804 84:
805   (SUBTYPEP '(SATISFIES SOME-UNDEFINED-FUN) NIL)=>NIL,T (should be NIL,NIL)
806
807 85:
808   Internally the compiler sometimes evaluates
809     (sb-kernel:type/= (specifier-type '*) (specifier-type t))
810   (I stumbled across this when I added an
811     (assert (not (eq type1 *wild-type*)))
812   in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
813   in a type context should probably be translated to T, and so it's
814   probably to ask whether it's equal to the T type and then (using the
815   EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
816   (I haven't tried to investigate this bug enough to guess whether
817   there might be any user-level symptoms.)
818
819 87:
820   Despite what the manual says, (DECLAIM (SPEED 0)) doesn't cause
821   things to be byte compiled. This seems to be true in cmucl-2.4.19,
822   too: (COMPILE-FILE .. :BYTE-COMPILE T) causes byte-compilation,
823   but ordinary COMPILE-FILE of a file containing (DECLAIM (SPEED 0))
824   does not.
825
826 90: 
827   a latent cross-compilation/bootstrapping bug: The cross-compilation
828   host's CL:CHAR-CODE-LIMIT is used in target code in readtable.lisp
829   and possibly elsewhere. Instead, we should use the target system's
830   CHAR-CODE-LIMIT. This will probably cause problems if we try to 
831   bootstrap on a system which uses a different value of CHAR-CODE-LIMIT
832   than SBCL does.
833
834
835 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
836
837 (Note: At some point, the pure interpreter (actually a semi-pure
838 interpreter aka "the IR1 interpreter") will probably go away, replaced
839 by constructs like
840   (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
841 and at that time these bugs should either go away automatically or
842 become more tractable to fix. Until then, they'll probably remain,
843 since some of them aren't considered urgent, and the rest are too hard
844 to fix as long as so many special cases remain. After the IR1
845 interpreter goes away is also the preferred time to start
846 systematically exterminating cases where debugging functionality
847 (backtrace, breakpoint, etc.) breaks down, since getting rid of the
848 IR1 interpreter will reduce the number of special cases we need to
849 support.)
850
851 IR1-1:
852   The FUNCTION special operator doesn't check properly whether its
853   argument is a function name. E.g. (FUNCTION (X Y)) returns a value
854   instead of failing with an error. (Later attempting to funcall the
855   value does cause an error.) 
856
857 IR1-2:
858   COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
859         * (DEFUN FOO (X) (- 12 X))
860         FOO
861         * (COMPILED-FUNCTION-P #'FOO)
862         T
863
864 IR1-3:
865   Executing 
866     (DEFVAR *SUPPRESS-P* T)
867     (EVAL '(UNLESS *SUPPRESS-P*
868              (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
869                (FORMAT T "surprise!"))))
870   prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
871   rewritten from scratch to conform to the ANSI definition, abandoning
872   the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
873   in the original CMU CL source, too). This should be easier to do --
874   though still nontrivial -- once the various IR1 interpreter special
875   cases are gone.
876
877 IR1-3a:
878   EVAL-WHEN's idea of what's a toplevel form is even more screwed up 
879   than the example in IR1-3 would suggest, since COMPILE-FILE and
880   COMPILE both print both "right now!" messages when compiling the
881   following code,
882     (LAMBDA (X)
883       (COND (X
884              (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
885                (PRINT "yes! right now!"))
886              "yes!")
887             (T
888              (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
889                (PRINT "no! right now!"))
890              "no!")))
891   and while EVAL doesn't print the "right now!" messages, the first
892   FUNCALL on the value returned by EVAL causes both of them to be printed.
893
894 IR1-4:
895   The system accepts DECLAIM in most places where DECLARE would be 
896   accepted, without even issuing a warning. ANSI allows this, but since
897   it's fairly easy to mistype DECLAIM instead of DECLARE, and the
898   meaning is rather different, and it's unlikely that the user
899   has a good reason for doing DECLAIM not at top level, it would be 
900   good to issue a STYLE-WARNING when this happens. A possible
901   fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
902   or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
903   [This is considered an IR1-interpreter-related bug because until
904   EVAL-WHEN is rewritten, which won't happen until after the IR1
905   interpreter is gone, the system's notion of what's a top-level form
906   and what's not will remain too confused to fix this problem.]