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