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 4:
  80   It should cause a note, not a WARNING, when the system ignores
  81   an FTYPE proclamation for a slot accessor.
  82
  83 5:
  84   Error reporting on various stream-requiring operations is not
  85   very good when the stream argument has the wrong type, because
  86   the operation tries to fall through to Gray stream code, and then
  87   dies because it's undefined. E.g.
  88     (PRINT-UNREADABLE-OBJECT (*STANDARD-OUTPUT* 1)) ..)
  89   gives the error message
  90     error in SB-KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
  91       The function SB-IMPL::STREAM-WRITE-STRING is undefined.
  92   It would be more useful and correct to signal a TYPE-ERROR:
  93     not a STREAM: 1
  94   (It wouldn't be terribly difficult to write stubs for all the
  95   Gray stream functions that the old CMU CL code expects, with
  96   each stub just raising the appropriate TYPE-ERROR.)
  97
  98 6:
  99   bogus warnings about undefined functions for magic functions like
 100   SB!C::%%DEFUN and SB!C::%DEFCONSTANT when cross-compiling files
 101   like src/code/float.lisp
 102
 103 7:
 104   The "byte compiling top-level form:" output ought to be condensed.
 105   Perhaps any number of such consecutive lines ought to turn into a
 106   single "byte compiling top-level forms:" line.
 107
 108 8:
 109   Compiling a file containing the erroneous program
 110         (DEFSTRUCT FOO
 111           A
 112           B)
 113         (DEFSTRUCT (BAR (:INCLUDE FOO))
 114           A
 115           B)
 116   gives only the not-very-useful message
 117         caught ERROR:
 118           (during macroexpansion)
 119         Condition PROGRAM-ERROR was signalled.
 120   (The specific message which says that the problem was duplicate
 121   slot names gets lost.)
 122
 123 9:
 124   The handling of IGNORE declarations on lambda list arguments of
 125   DEFMETHOD is at least weird, and in fact seems broken and useless.
 126   I should fix up another layer of binding, declared IGNORABLE, for
 127   typed lambda list arguments.
 128
 129 10:
 130   The way that the compiler munges types with arguments together
 131   with types with no arguments (in e.g. TYPE-EXPAND) leads to
 132   weirdness visible to the user:
 133         (DEFTYPE FOO () 'FIXNUM)
 134         (TYPEP 11 'FOO) => T
 135         (TYPEP 11 '(FOO)) => T, which seems weird
 136         (TYPEP 11 'FIXNUM) => T
 137         (TYPEP 11 '(FIXNUM)) signals an error, as it should
 138   The situation is complicated by the presence of Common Lisp types
 139   like UNSIGNED-BYTE (which can either be used in list form or alone)
 140   so I'm not 100% sure that the behavior above is actually illegal.
 141   But I'm 90+% sure, and someday perhaps I'll be motivated to look it up..
 142
 143 11:
 144   It would be nice if the
 145         caught ERROR:
 146           (during macroexpansion)
 147   said what macroexpansion was at fault, e.g.
 148         caught ERROR:
 149           (during macroexpansion of IN-PACKAGE,
 150           during macroexpansion of DEFFOO)
 151
 152 12:
 153   The type system doesn't understand the KEYWORD type very well:
 154         (SUBTYPEP 'KEYWORD 'SYMBOL) => NIL, NIL
 155   It might be possible to fix this by changing the definition of
 156   KEYWORD to (AND SYMBOL (SATISFIES KEYWORDP)), but the type system
 157   would need to be a bit smarter about AND types, too:
 158         (SUBTYPEP '(AND SYMBOL KEYWORD) 'SYMBOL) => NIL, NIL
 159   (The type system does know something about AND types already,
 160         (SUBTYPEP '(AND INTEGER FLOAT) 'NUMBER) => T, T
 161         (SUBTYPEP '(AND INTEGER FIXNUM) 'NUMBER) =>T, T
 162   so likely this is a small patch.)
 163
 164 13:
 165   Floating point infinities are screwed up. [When I was converting CMU CL
 166   to SBCL, I was looking for complexity to delete, and I thought it was safe
 167   to just delete support for floating point infinities. It wasn't: they're
 168   generated by the floating point hardware even when we remove support
 169   for them in software. -- WHN] Support for them should be restored.
 170
 171 14:
 172   The ANSI syntax for non-STANDARD method combination types in CLOS is
 173         (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
 174         (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
 175   If you mess this up, omitting the PROGN qualifier in in DEFMETHOD,
 176         (DEFGENERIC FOO (X) (:METHOD-COMBINATION PROGN))
 177         (DEFMETHOD FOO ((X BAR)) (PRINT 'NUMBER))
 178   the error mesage is not easy to understand:
 179            INVALID-METHOD-ERROR was called outside the dynamic scope
 180         of a method combination function (inside the body of
 181         DEFINE-METHOD-COMBINATION or a method on the generic
 182         function COMPUTE-EFFECTIVE-METHOD).
 183   It would be better if it were more informative, a la
 184            The method combination type for this method (STANDARD) does
 185         not match the method combination type for the generic function
 186         (PROGN).
 187   Also, after you make the mistake of omitting the PROGN qualifier
 188   on a DEFMETHOD, doing a new DEFMETHOD with the correct qualifier
 189   no longer works:
 190         (DEFMETHOD FOO PROGN ((X BAR)) (PRINT 'NUMBER))
 191   gives
 192            INVALID-METHOD-ERROR was called outside the dynamic scope
 193         of a method combination function (inside the body of
 194         DEFINE-METHOD-COMBINATION or a method on the generic
 195         function COMPUTE-EFFECTIVE-METHOD).
 196   This is not very helpful..
 197
 198 15:
 199   (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
 200             '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
 201   (Also, when this is fixed, we can enable the code in PROCLAIM which
 202   checks for incompatible FTYPE redeclarations.)
 203
 204 16:
 205   The ANSI spec says that CONS can be a compound type spec, e.g.
 206   (CONS FIXNUM REAL). SBCL doesn't support this.
 207
 208 17:
 209   from Paolo Amoroso on the CMU CL mailing list 27 Feb 2000:
 210 I use CMU CL 18b under Linux. When COMPILE-FILE is supplied a physical
 211 pathname, the type of the corresponding compiled file is X86F:
 212         * (compile-file "/home/paolo/lisp/tools/foo")
 213         Python version 1.0, VM version Intel x86 on 27 FEB 0 06:00:46 pm.
 214         Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
 215         Converted SQUARE.
 216         Compiling DEFUN SQUARE:
 217         Byte Compiling Top-Level Form:
 218         /home/paolo/lisp/tools/foo.x86f written.
 219         Compilation finished in 0:00:00.
 220         #p"/home/paolo/lisp/tools/foo.x86f"
 221         NIL
 222         NIL
 223 But when the function is called with a logical pathname, the file type
 224 becomes FASL:
 225         * (compile-file "tools:foo")
 226         Python version 1.0, VM version Intel x86 on 27 FEB 0 06:01:04 pm.
 227         Compiling: /home/paolo/lisp/tools/foo.lisp 27 FEB 0 05:57:42 pm
 228         Converted SQUARE.
 229         Compiling DEFUN SQUARE:
 230         Byte Compiling Top-Level Form:
 231         TOOLS:FOO.FASL written.
 232         Compilation finished in 0:00:00.
 233         #p"/home/paolo/lisp/tools/foo.fasl"
 234         NIL
 235         NIL
 236
 237 18:
 238   from DTC on the CMU CL mailing list 25 Feb 2000:
 239 ;;; Compiler fails when this file is compiled.
 240 ;;;
 241 ;;; Problem shows up in delete-block within ir1util.lisp. The assertion
 242 ;;; (assert (member (functional-kind lambda) '(:let :mv-let :assignment)))
 243 ;;; fails within bind node branch.
 244 ;;;
 245 ;;; Note that if c::*check-consistency* is enabled then an un-reached
 246 ;;; entry is also reported.
 247 ;;;
 248 (defun foo (val)
 249   (declare (values nil))
 250   nil)
 251 (defun bug (val)
 252   (multiple-value-call
 253       #'(lambda (res)
 254           (block nil
 255             (tagbody
 256              loop
 257                (when res
 258                  (return nil))
 259                (go loop))))
 260     (foo val))
 261   (catch 'ccc1
 262     (throw 'ccc1
 263       (block bbbb
 264         (tagbody
 265
 266            (let ((ttt #'(lambda () (go cccc))))
 267              (declare (special ttt))
 268              (return-from bbbb nil))
 269
 270          cccc
 271            (return-from bbbb nil))))))
 272
 273 19:
 274   (I *think* this is a bug. It certainly seems like strange behavior. But
 275   the ANSI spec is scary, dark, and deep..)
 276     (FORMAT NIL  "~,1G" 1.4) => "1.    "
 277     (FORMAT NIL "~3,1G" 1.4) => "1.    "
 278
 279 20:
 280   from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
 281         (defclass ccc () ())
 282         (setf (find-class 'ccc1) (find-class 'ccc))
 283         (defmethod zut ((c ccc1)) 123)
 284   DTC's recommended workaround from the mailing list 3 Mar 2000:
 285         (setf (pcl::find-class 'ccc1) (pcl::find-class 'ccc))
 286
 287 22:
 288   The ANSI spec, in section "22.3.5.2 Tilde Less-Than-Sign: Logical Block",
 289   says that an error is signalled if ~W, ~_, ~<...~:>, ~I, or ~:T is used
 290   inside "~<..~>" (without the colon modifier on the closing syntax).
 291   However, SBCL doesn't do this:
 292         * (FORMAT T "~<munge~wegnum~>" 12)
 293         munge12egnum
 294         NIL
 295
 296 23:
 297   When too many files are opened, OPEN will fail with an
 298   uninformative error message
 299         error in function OPEN: error opening #P"/tmp/foo.lisp": NIL
 300   instead of saying that too many files are open.
 301
 302 24:
 303   Right now, when COMPILE-FILE has a read error, it actually pops
 304   you into the debugger before giving up on the file. It should
 305   instead handle the error, perhaps issuing (and handling)
 306   a secondary error "caught ERROR: unrecoverable error during compilation"
 307   and then return with FAILURE-P true,
 308
 309 25:
 310   from CMU CL mailing list 01 May 2000
 311
 312 I realize I can take care of this by doing (proclaim (ignore pcl::.slots1.))
 313 but seeing as .slots0. is not-exported, shouldn't it be ignored within the
 314 +expansion
 315 when not used?
 316
 317 In: DEFMETHOD FOO-BAR-BAZ (RESOURCE-TYPE)
 318   (DEFMETHOD FOO-BAR-BAZ
 319              ((SELF RESOURCE-TYPE))
 320              (SETF (SLOT-VALUE SELF 'NAME) 3))
 321 --> BLOCK MACROLET PCL::FAST-LEXICAL-METHOD-FUNCTIONS
 322 --> PCL::BIND-FAST-LEXICAL-METHOD-MACROS MACROLET
 323 --> PCL::BIND-LEXICAL-METHOD-FUNCTIONS LET PCL::BIND-ARGS LET* PCL::PV-BINDING
 324 --> PCL::PV-BINDING1 PCL::PV-ENV LET
 325 ==>
 326   (LET ((PCL::.SLOTS0. #))
 327     (PROGN SELF)
 328     (BLOCK FOO-BAR-BAZ
 329       (LET #
 330         #)))
 331 Warning: Variable PCL::.SLOTS0. defined but never used.
 332
 333 Compilation unit finished.
 334   1 warning
 335
 336 #<Standard-Method FOO-BAR-BAZ (RESOURCE-TYPE) {480918FD}>
 337
 338 26:
 339   reported by Sam Steingold on the cmucl-imp mailing list 12 May 2000:
 340
 341 Also, there is another bug: `array-displacement' should return an array
 342 or nil as first value (as per ANSI CL), while CMUCL declares it as
 343 returning an array as first value always.
 344
 345 27:
 346   Sometimes (SB-EXT:QUIT) fails with
 347         Argh! maximum interrupt nesting depth (4096) exceeded, exiting
 348         Process inferior-lisp exited abnormally with code 1
 349   I haven't noticed a repeatable case of this yet.
 350
 351 29:
 352   some sort of bug in inlining and RETURN-FROM in sbcl-0.6.5: Compiling
 353     (DEFUN BAR? (X)
 354       (OR (NAR? X)
 355           (BLOCK USED-BY-SOME-Y?
 356             (FLET ((FROB (STK)
 357                      (DOLIST (Y STK)
 358                        (UNLESS (REJECTED? Y)
 359                          (RETURN-FROM USED-BY-SOME-Y? T)))))
 360               (DECLARE (INLINE FROB))
 361               (FROB (RSTK X))
 362               (FROB (MRSTK X)))
 363             NIL)))
 364   gives
 365    error in function SB-KERNEL:ASSERT-ERROR:
 366    The assertion (EQ (SB-C::CONTINUATION-KIND SB-C::CONT) :BLOCK-START) failed.
 367   This is still present in sbcl-0.6.8.
 368
 369 30:
 370   The CMU CL reader code takes liberties in binding the standard read table
 371   when reading the names of characters. Tim Moore posted a patch to the
 372   CMU CL mailing list Mon, 22 May 2000 21:30:41 -0700.
 373
 374 31:
 375   In some cases the compiler believes type declarations on array
 376   elements without checking them, e.g.
 377         (DECLAIM (OPTIMIZE (SAFETY 3) (SPEED 1) (SPACE 1)))
 378         (DEFSTRUCT FOO A B)
 379         (DEFUN BAR (X)
 380           (DECLARE (TYPE (SIMPLE-ARRAY CONS 1) X))
 381           (WHEN (CONSP (AREF X 0))
 382             (PRINT (AREF X 0))))
 383         (BAR (VECTOR (MAKE-FOO :A 11 :B 12)))
 384   prints
 385         #S(FOO :A 11 :B 12)
 386   in SBCL 0.6.5 (and also in CMU CL 18b). This does not happen for
 387   all cases, e.g. the type assumption *is* checked if the array
 388   elements are declared to be of some structure type instead of CONS.
 389
 390 32:
 391   The printer doesn't report closures very well. This is true in
 392   CMU CL 18b as well:
 393     (PRINT #'CLASS-NAME)
 394   gives
 395     #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
 396   It would be nice to make closures have a settable name slot,
 397   and make things like DEFSTRUCT and FLET, which create closures,
 398   set helpful values into this slot.
 399
 400 33:
 401   And as long as we're wishing, it would be awfully nice if INSPECT could
 402   also report on closures, telling about the values of the bound variables.
 403
 404 34:
 405   as reported by Robert Strandh on the CMU CL mailing list 12 Jun 2000:
 406     $ cat xx.lisp
 407     (defconstant +a-constant+ (make-instance 'a-class))
 408     (defconstant +another-constant+ (vector +a-constant+))
 409     $ lisp
 410     CMU Common Lisp release x86-linux 2.4.19  8 February 2000 build 456,
 411     running on
 412     bobby
 413     Send bug reports and questions to your local CMU CL maintainer,
 414     or to pvaneynd@debian.org
 415     or to cmucl-help@cons.org. (prefered)
 416     type (help) for help, (quit) to exit, and (demo) to see the demos
 417     Loaded subsystems:
 418       Python 1.0, target Intel x86
 419       CLOS based on PCL version:  September 16 92 PCL (f)
 420     * (defclass a-class () ())
 421     #<STANDARD-CLASS A-CLASS {48027BD5}>
 422     * (compile-file "xx.lisp")
 423     Python version 1.0, VM version Intel x86 on 12 JUN 00 08:12:55 am.
 424     Compiling:
 425     /home/strandh/Research/Functional/Common-Lisp/CLIM/Development/McCLIM
 426     /xx.lisp 12 JUN 00 07:47:14 am
 427     Compiling Load Time Value of (PCL::GET-MAKE-INSTANCE-FUNCTION-SYMBOL
 428     '(A-CLASS NIL NIL)):
 429     Byte Compiling Top-Level Form:
 430     Error in function C::DUMP-STRUCTURE:  Attempt to dump invalid
 431     structure:
 432       #<A-CLASS {4803A5B5}>
 433     How did this happen?
 434
 435 35:
 436   The compiler assumes that any time a function of declared FTYPE
 437   doesn't signal an error, its arguments were of the declared type.
 438   E.g. compiling and loading
 439     (DECLAIM (OPTIMIZE (SAFETY 3)))
 440     (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
 441     (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE) FACTORIAL)))
 442     (DEFUN FOO (X)
 443       (COND ((> (FACTORIAL X) 1.0E6)
 444              (FORMAT T "too big~%"))
 445             ((INTEGERP X)
 446              (FORMAT T "exactly ~S~%" (FACTORIAL X)))
 447             (T
 448              (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
 449   then executing
 450     (FOO 1.5)
 451   will cause the INTEGERP case to be selected, giving bogus output a la
 452     exactly 1.33..
 453   This violates the "declarations are assertions" principle.
 454   According to the ANSI spec, in the section "System Class FUNCTION",
 455   this is a case of "lying to the compiler", but the lying is done
 456   by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
 457   not by the unexpectedly general definition of FACTORIAL. In any case,
 458   "declarations are assertions" means that lying to the compiler should
 459   cause an error to be signalled, and should not cause a bogus
 460   result to be returned. Thus, the compiler should not assume
 461   that arbitrary functions check their argument types. (It might
 462   make sense to add another flag (CHECKED?) to DEFKNOWN to
 463   identify functions which *do* check their argument types.)
 464
 465 36:
 466   As pointed out by Martin Cracauer on the CMU CL mailing list
 467   13 Jun 2000, the :FILE-LENGTH operation for
 468   FD-STREAM-MISC-ROUTINE is broken for large files: it says
 469   (THE INDEX SIZE) even though SIZE can be larger than INDEX.
 470
 471 37:
 472   In SBCL 0.6.5 (and CMU CL 18b) compiling and loading
 473         (in-package :cl-user)
 474         (declaim (optimize (safety 3)
 475                            (debug 3)
 476                            (compilation-speed 2)
 477                            (space 1)
 478                            (speed 2)
 479                            #+nil (sb-ext:inhibit-warnings 2)))
 480         (declaim (ftype (function * (values)) emptyvalues))
 481         (defun emptyvalues (&rest rest) (declare (ignore rest)) (values))
 482         (defstruct foo x y)
 483         (defgeneric assertoid ((x t)))
 484         (defmethod assertoid ((x t)) "just a placeholder")
 485         (defun bar (ht)
 486           (declare (type hash-table ht))
 487           (let ((res
 488                  (block blockname
 489                    (progn
 490                     (prog1
 491                         (emptyvalues)
 492                       (assertoid (hash-table-count ht)))))))
 493             (unless (typep res 'foo)
 494               (locally
 495                (common-lisp-user::bad-result-from-assertive-typed-fun
 496                 'bar
 497                 res)))))
 498   then executing
 499         (bar (make-hash-table))
 500   causes the failure
 501         Error in KERNEL::UNDEFINED-SYMBOL-ERROR-HANDLER:
 502           the function C::%INSTANCE-TYPEP is undefined.
 503   %INSTANCE-TYPEP is always supposed to be IR1-transformed away, but for
 504   some reason -- the (VALUES) return value declaration? -- the optimizer is
 505   confused and compiles a full call to %INSTANCE-TYPEP (which doesn't exist
 506   as a function) instead.
 507
 508 37a:
 509   The %INSTANCE-TYPEP problem in bug 37 comes up also when compiling
 510   and loading
 511         (IN-PACKAGE :CL-USER)
 512         (LOCALLY
 513           (DECLARE (OPTIMIZE (SAFETY 3) (SPEED 2) (SPACE 2)))
 514           (DECLAIM (FTYPE (FUNCTION (&REST T) (VALUES)) EMPTYVALUES))
 515           (DEFUN EMPTYVALUES (&REST REST)
 516             (DECLARE (IGNORE REST))
 517             (VALUES))
 518           (DEFSTRUCT DUMMYSTRUCT X Y)
 519           (DEFUN FROB-EMPTYVALUES (X)
 520             (LET ((RES (EMPTYVALUES X X X)))
 521               (UNLESS (TYPEP RES 'DUMMYSTRUCT)
 522                 'EXPECTED-RETURN-VALUE))))
 523         (ASSERT (EQ (FROB-EMPTYVALUES 11) 'EXPECTED-RETURN-VALUE))
 524
 525
 526 38:
 527   DEFMETHOD doesn't check the syntax of &REST argument lists properly,
 528   accepting &REST even when it's not followed by an argument name:
 529         (DEFMETHOD FOO ((X T) &REST) NIL)
 530
 531 39:
 532   On the CMU CL mailing list 26 June 2000, Douglas Crosher wrote
 533
 534   Hannu Rummukainen wrote:
 535   ...
 536   > There's something weird going on with the compilation of the attached
 537   > code.  Compiling and loading the file in a fresh lisp, then invoking
 538   > (test-it) gives
 539   Thanks for the bug report, nice to have this one fixed. It was a bug
 540   in the x86 backend, the < VOP. A fix has been committed to the main
 541   source, see the file compiler/x86/float.lisp.
 542
 543   Probably the same bug exists in SBCL.
 544
 545 40:
 546   TYPEP treats the result of UPGRADED-ARRAY-ELEMENT-TYPE as gospel,
 547   so that (TYPEP (MAKE-ARRAY 3) '(VECTOR SOMETHING-NOT-DEFINED-YET))
 548   returns (VALUES T T). Probably it should be an error instead,
 549   complaining that the type SOMETHING-NOT-DEFINED-YET is not defined.
 550
 551 41:
 552   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in
 553         (DEFTYPE INDEXOID () '(INTEGER 0 1000))
 554         (DEFUN FOO (X)
 555           (DECLARE (TYPE INDEXOID X))
 556           (THE (VALUES INDEXOID)
 557             (VALUES X)))
 558   where the implementation of the type check in function FOO
 559   includes a full call to %TYPEP. There are also some fundamental problems
 560   with the interpretation of VALUES types (inherited from CMU CL, and
 561   from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
 562   mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
 563
 564 42:
 565   The definitions of SIGCONTEXT-FLOAT-REGISTER and
 566   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
 567   supported on FreeBSD because the floating point state is not saved,
 568   but at least as of FreeBSD 4.0, the floating point state *is* saved,
 569   so they could be supported after all. Very likely
 570   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 571
 572 43:
 573   (as discussed by Douglas Crosher on the cmucl-imp mailing list ca.
 574   Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
 575   issue with 'union, 'and, 'or etc. So even though according to the
 576   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
 577   (and now SBCL) interpret them as legal types.
 578
 579 44:
 580   ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
 581   CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
 582   list, and it is probably possible to use substantially the same
 583   patches to add it to SBCL.
 584
 585 45:
 586   a slew of floating-point-related errors reported by Peter Van Eynde
 587   on July 25, 2000:
 588         a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
 589            Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
 590            aren't found.
 591         b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
 592            should probably be 1.4012985e-45. In SBCL,
 593            (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
 594            than LEAST-POSITIVE-SHORT-FLOAT. Similar problems
 595            exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
 596            and LEAST-NEGATIVE-LONG-FLOAT.
 597         c: Many expressions generate floating infinity:
 598                 (/ 1 0.0)
 599                 (/ 1 0.0d0)
 600                 (EXPT 10.0 1000)
 601                 (EXPT 10.0d0 1000)
 602            PVE's regression tests want them to raise errors. SBCL
 603            generates the infinities instead, which may or may not be
 604            conforming behavior, but then blow it by being unable to
 605            output the infinities, since support for infinities is generally
 606            broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
 607            undefined.
 608         d: (in section12.erg) various forms a la
 609                 (FLOAT 1 DOUBLE-FLOAT-EPSILON)
 610            don't give the right behavior.
 611
 612 46:
 613   type safety errors reported by Peter Van Eynde July 25, 2000:
 614         a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
 615            => #(A B C)
 616            In general lengths of array type specifications aren't
 617            checked by COERCE, so it fails when the spec is
 618            (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
 619         b: CONCATENATE has the same problem of not checking the length
 620            of specified output array types. MAKE-SEQUENCE and MAP and
 621            MERGE also have the same problem.
 622         c: (COERCE 'AND 'FUNCTION) returns something related to
 623            (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
 624         d: ELT signals SIMPLE-ERROR if its index argument
 625            isn't a valid index for its sequence argument, but should
 626            signal TYPE-ERROR instead.
 627         e: FILE-LENGTH is supposed to signal a type error when its
 628            argument is not a stream associated with a file, but doesn't.
 629         f: (FLOAT-RADIX 2/3) should signal an error instead of
 630            returning 2.
 631         g: (LOAD "*.lsp") should signal FILE-ERROR.
 632         h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
 633            should signal TYPE-ERROR.
 634         i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
 635            be used for input and output as needed. It should fail with
 636            TYPE-ERROR when handed e.g. the results of
 637            MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
 638            the inappropriate positions, but doesn't.
 639         j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
 640                             (QUOTE STRING)))
 641            should probably signal an error instead of making a pathname with
 642            a null byte in it.
 643         k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
 644            not a binary input stream, but instead cheerfully reads from
 645            character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 646
 647 47:
 648   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
 649         a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
 650            doesn't.
 651         b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
 652            signal a PROGRAM-ERROR, and doesn't.
 653         c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
 654            and other DEFCLASS forms with duplicate specifications in their
 655            slots, should signal a PROGRAM-ERROR, and doesn't.
 656         d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
 657            causes a COMPILER-ERROR.
 658
 659 48:
 660   SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
 661         a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal
 662            PROGRAM-ERROR, but SBCL accepts it instead.
 663         b: SYMBOL-MACROLET should refuse to bind something which is
 664            declared as a global variable, signalling PROGRAM-ERROR.
 665         c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
 666            it binds is declared SPECIAL inside.
 667
 668 49:
 669   LOOP bugs reported by Peter Van Eynde July 25, 2000:
 670         a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
 671            the definition of WITH clauses given in the ANSI spec, but
 672            compiles and runs happily in SBCL.
 673         b: a messy one involving package iteration:
 674 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<))))
 675 Should be: (("blah" "blah2") ("blah2"))
 676 SBCL: (("blah") ("blah2"))
 677         * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
 678           doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
 679
 680 50:
 681   type system errors reported by Peter Van Eynde July 25, 2000:
 682         a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
 683            but should be (VALUES T T) instead.
 684         b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL
 685            but should be (VALUES T T) instead.
 686         c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
 687         d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
 688            blows up at the level of SPECIFIER-TYPE with
 689            "Lower bound (0) is greater than upper bound (0)." Probably
 690            SPECIFIER-TYPE should return NIL instead.
 691         e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
 692            "Component type for Complex is not numeric: (EQL 0)."
 693            This might be easy to fix; the type system already knows
 694            that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
 695         f: The type system doesn't know about the condition system,
 696            so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL.
 697         g: The type system isn't all that smart about relationships
 698            between hairy types, as shown in the type.erg test results,
 699            e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
 700
 701 51:
 702   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
 703         a: (PROGN
 704             (DEFGENERIC FOO02 (X))
 705             (DEFMETHOD FOO02 ((X NUMBER)) T)
 706             (LET ((M (FIND-METHOD (FUNCTION FOO02)
 707                                   NIL
 708                                   (LIST (FIND-CLASS (QUOTE NUMBER))))))
 709               (REMOVE-METHOD (FUNCTION FOO02) M)
 710               (DEFGENERIC FOO03 (X))
 711               (ADD-METHOD (FUNCTION FOO03) M)))
 712            should give an error, but SBCL allows it.
 713         b: READ should probably return READER-ERROR, not the bare
 714            arithmetic error, when input a la "1/0" or "1e1000" causes
 715            an arithmetic error.
 716
 717 52:
 718   It has been reported (e.g. by Peter Van Eynde) that there are
 719   several metaobject protocol "errors". (In order to fix them, we might
 720   need to document exactly what metaobject protocol specification
 721   we're following -- the current code is just inherited from PCL.)
 722
 723 53:
 724   another error from Peter Van Eynde 5 September 2000:
 725   (FORMAT NIL "~F" "FOO") should work, but instead reports an error.
 726   PVE submitted a patch to deal with this bug, but it exposes other
 727   comparably serious bugs, so I didn't apply it. It looks as though
 728   the FORMAT code needs a fair amount of rewriting in order to comply
 729   with the various details of the ANSI spec.
 730
 731 54:
 732   The implementation of #'+ returns its single argument without
 733   type checking, e.g. (+ "illegal") => "illegal".
 734
 735 55:
 736   In sbcl-0.6.7, there is no doc string for CL:PUSH, probably
 737   because it's defined with the DEFMACRO-MUNDANELY macro and something
 738   is wrong with doc string setting in that macro.
 739
 740 56:
 741   Attempting to use COMPILE on something defined by DEFMACRO fails:
 742         (DEFMACRO FOO (X) (CONS X X))
 743         (COMPILE 'FOO)
 744 Error in function C::GET-LAMBDA-TO-COMPILE:
 745    #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
 746
 747 58:
 748   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
 749   => NIL, NIL
 750
 751 59:
 752   CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
 753   current working directory). And there's no supported way to update
 754   or query the current working directory (a la Unix "chdir" and "pwd"),
 755   which is functionality that ILISP needs (and currently gets with low-level
 756   hacks).
 757
 758 60:
 759   The debugger LIST-LOCATIONS command doesn't work properly.
 760
 761 61:
 762   Compiling and loading
 763     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
 764     (FAIL 12)
 765   then requesting a BACKTRACE at the debugger prompt gives no information
 766   about where in the user program the problem occurred.
 767
 768 62:
 769   The compiler is supposed to do type inference well enough that
 770   the declaration in
 771     (TYPECASE X
 772       ((SIMPLE-ARRAY SINGLE-FLOAT)
 773        (LOCALLY
 774          (DECLARE (TYPE (SIMPLE-ARRAY SINGLE-FLOAT) X))
 775          ..))
 776       ..)
 777   is redundant. However, as reported by Juan Jose Garcia Ripoll for
 778   CMU CL, it sometimes doesn't. Adding declarations is a pretty good
 779   workaround for the problem for now, but can't be done by the TYPECASE
 780   macros themselves, since it's too hard for the macro to detect
 781   assignments to the variable within the clause.
 782     Note: The compiler *is* smart enough to do the type inference in
 783   many cases. This case, derived from a couple of MACROEXPAND-1
 784   calls on Ripoll's original test case,
 785     (DEFUN NEGMAT (A)
 786       (DECLARE (OPTIMIZE SPEED (SAFETY 0)))
 787       (COND ((TYPEP A '(SIMPLE-ARRAY SINGLE-FLOAT)) NIL
 788              (LET ((LENGTH (ARRAY-TOTAL-SIZE A)))
 789                (LET ((I 0) (G2554 LENGTH))
 790                  (DECLARE (TYPE REAL G2554) (TYPE REAL I))
 791                  (TAGBODY
 792                   SB-LOOP::NEXT-LOOP
 793                   (WHEN (>= I G2554) (GO SB-LOOP::END-LOOP))
 794                   (SETF (ROW-MAJOR-AREF A I) (- (ROW-MAJOR-AREF A I)))
 795                   (GO SB-LOOP::NEXT-LOOP)
 796                   SB-LOOP::END-LOOP))))))
 797   demonstrates the problem; but the problem goes away if the TAGBODY
 798   and GO forms are removed (leaving the SETF in ordinary, non-looping
 799   code), or if the TAGBODY and GO forms are retained, but the
 800   assigned value becomes 0.0 instead of (- (ROW-MAJOR-AREF A I)).
 801
 802 63:
 803   Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
 804     I am looking into this problem that showed up on the cmucl-help
 805     list. It seems to me that the "implementation specific environment
 806     hacking functions" found in pcl/walker.lisp are completely messed
 807     up. The good thing is that they appear to be barely used within
 808     PCL and the munged environment object is passed to cmucl only
 809     in calls to macroexpand-1, which is probably why this case fails.
 810   SBCL uses essentially the same code, so if the environment hacking
 811   is screwed up, it affects us too.
 812
 813 64:
 814   Using the pretty-printer from the command prompt gives funny
 815   results, apparently because the pretty-printer doesn't know
 816   about user's command input, including the user's carriage return
 817   that the user, and therefore the pretty-printer thinks that
 818   the new output block should start indented 2 or more characters
 819   rightward of the correct location.
 820
 821 65:
 822   As reported by Carl Witty on submit@bugs.debian.org 1999-05-08,
 823   compiling this file
 824 (in-package "CL-USER")
 825 (defun equal-terms (termx termy)
 826   (labels
 827     ((alpha-equal-bound-term-lists (listx listy)
 828        (or (and (null listx) (null listy))
 829            (and listx listy
 830                 (let ((bindings-x (bindings-of-bound-term (car listx)))
 831                       (bindings-y (bindings-of-bound-term (car listy))))
 832                   (if (and (null bindings-x) (null bindings-y))
 833                       (alpha-equal-terms (term-of-bound-term (car listx))
 834                                          (term-of-bound-term (car listy)))
 835                       (and (= (length bindings-x) (length bindings-y))
 836                            (prog2
 837                                (enter-binding-pairs (bindings-of-bound-term (car listx))
 838                                                     (bindings-of-bound-term (car listy)))
 839                                (alpha-equal-terms (term-of-bound-term (car listx))
 840                                                   (term-of-bound-term (car listy)))
 841                              (exit-binding-pairs (bindings-of-bound-term (car listx))
 842                                                  (bindings-of-bound-term (car listy)))))))
 843                 (alpha-equal-bound-term-lists (cdr listx) (cdr listy)))))
 844
 845      (alpha-equal-terms (termx termy)
 846        (if (and (variable-p termx)
 847                 (variable-p termy))
 848            (equal-bindings (id-of-variable-term termx)
 849                            (id-of-variable-term termy))
 850            (and (equal-operators-p (operator-of-term termx) (operator-of-term termy))
 851                 (alpha-equal-bound-term-lists (bound-terms-of-term termx)
 852                                               (bound-terms-of-term termy))))))
 853
 854     (or (eq termx termy)
 855         (and termx termy
 856              (with-variable-invocation (alpha-equal-terms termx termy))))))
 857   causes an assertion failure
 858     The assertion (EQ (C::LAMBDA-TAIL-SET C::CALLER)
 859                       (C::LAMBDA-TAIL-SET (C::LAMBDA-HOME C::CALLEE))) failed.
 860
 861   Bob Rogers reports (1999-07-28 on cmucl-imp@cons.org) a smaller test
 862   case with the same problem:
 863 (defun parse-fssp-alignment ()
 864   ;; Given an FSSP alignment file named by the argument . . .
 865   (labels ((get-fssp-char ()
 866              (get-fssp-char))
 867            (read-fssp-char ()
 868              (get-fssp-char)))
 869     ;; Stub body, enough to tickle the bug.
 870     (list (read-fssp-char)
 871           (read-fssp-char))))
 872
 873 66:
 874   ANSI specifies that the RESULT-TYPE argument of CONCATENATE must be
 875   a subtype of SEQUENCE, but CONCATENATE doesn't check this properly:
 876     (CONCATENATE 'SIMPLE-ARRAY #(1 2) '(3)) => #(1 2 3)
 877   This also leads to funny behavior when derived type specifiers
 878   are used, as originally reported by Milan Zamazal for CMU CL (on the
 879   Debian bugs mailing list (?) 2000-02-27), then reported by Martin
 880   Atzmueller for SBCL (2000-10-01 on sbcl-devel@lists.sourceforge.net):
 881     (DEFTYPE FOO () 'SIMPLE-ARRAY)
 882     (CONCATENATE 'FOO #(1 2) '(3))
 883       => #<ARRAY-TYPE SIMPLE-ARRAY> is a bad type specifier for
 884            sequence functions.
 885   The derived type specifier FOO should act the same way as the
 886   built-in type SIMPLE-ARRAY here, but it doesn't. That problem
 887   doesn't seem to exist for sequence types:
 888     (DEFTYPE BAR () 'SIMPLE-VECTOR)
 889     (CONCATENATE 'BAR #(1 2) '(3)) => #(1 2 3)
 890
 891
 892 KNOWN BUGS RELATED TO THE IR1 INTERPRETER
 893
 894 (Note: At some point, the pure interpreter (actually a semi-pure
 895 interpreter aka "the IR1 interpreter") will probably go away, replaced
 896 by constructs like
 897   (DEFUN EVAL (X) (FUNCALL (COMPILE NIL (LAMBDA ..)))))
 898 and at that time these bugs should either go away automatically or
 899 become more tractable to fix. Until then, they'll probably remain,
 900 since some of them aren't considered urgent, and the rest are too hard
 901 to fix as long as so many special cases remain. After the IR1
 902 interpreter goes away is also the preferred time to start
 903 systematically exterminating cases where debugging functionality
 904 (backtrace, breakpoint, etc.) breaks down, since getting rid of the
 905 IR1 interpreter will reduce the number of special cases we need to
 906 support.)
 907
 908 IR1-1:
 909   The FUNCTION special operator doesn't check properly whether its
 910   argument is a function name. E.g. (FUNCTION (X Y)) returns a value
 911   instead of failing with an error. (Later attempting to funcall the
 912   value does cause an error.)
 913
 914 IR1-2:
 915   COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
 916         * (DEFUN FOO (X) (- 12 X))
 917         FOO
 918         * (COMPILED-FUNCTION-P #'FOO)
 919         T
 920
 921 IR1-3:
 922   Executing
 923     (DEFVAR *SUPPRESS-P* T)
 924     (EVAL '(UNLESS *SUPPRESS-P*
 925              (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
 926                (FORMAT T "surprise!"))))
 927   prints "surprise!". Probably the entire EVAL-WHEN mechanism ought to be
 928   rewritten from scratch to conform to the ANSI definition, abandoning
 929   the *ALREADY-EVALED-THIS* hack which is used in sbcl-0.6.8.9 (and
 930   in the original CMU CL source, too). This should be easier to do --
 931   though still nontrivial -- once the various IR1 interpreter special
 932   cases are gone.
 933
 934 IR1-3a:
 935   EVAL-WHEN's idea of what's a toplevel form is even more screwed up
 936   than the example in IR1-3 would suggest, since COMPILE-FILE and
 937   COMPILE both print both "right now!" messages when compiling the
 938   following code,
 939     (LAMBDA (X)
 940       (COND (X
 941              (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
 942                (PRINT "yes! right now!"))
 943              "yes!")
 944             (T
 945              (EVAL-WHEN (:COMPILE-TOPLEVEL :LOAD-TOPLEVEL :EXECUTE)
 946                (PRINT "no! right now!"))
 947              "no!")))
 948   and while EVAL doesn't print the "right now!" messages, the first
 949   FUNCALL on the value returned by EVAL causes both of them to be printed.
 950
 951 IR1-4:
 952   The system accepts DECLAIM in most places where DECLARE would be
 953   accepted, without even issuing a warning. ANSI allows this, but since
 954   it's fairly easy to mistype DECLAIM instead of DECLARE, and the
 955   meaning is rather different, and it's unlikely that the user
 956   has a good reason for doing DECLAIM not at top level, it would be
 957   good to issue a STYLE-WARNING when this happens. A possible
 958   fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
 959   or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
 960   [This is considered an IR1-interpreter-related bug because until
 961   EVAL-WHEN is rewritten, which won't happen until after the IR1
 962   interpreter is gone, the system's notion of what's a top-level form
 963   and what's not will remain too confused to fix this problem.]