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