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 please please include enough information in a bug report
   9 that someone reading 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 At some point, the pure interpreter (aka the "IR1 interpreter") will
  28 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
  33 IR1-1:
  34   The FUNCTION special operator doesn't check properly whether its
  35   argument is a function name. E.g. (FUNCTION (X Y)) returns a value
  36   instead of failing with an error. (Later attempting to funcall the
  37   value does cause an error.)
  38
  39 IR1-2:
  40   COMPILED-FUNCTION-P bogusly reports T for interpreted functions:
  41         * (DEFUN FOO (X) (- 12 X))
  42         FOO
  43         * (COMPILED-FUNCTION-P #'FOO)
  44         T
  45
  46
  47 OTHER KNOWN BUGS:
  48
  49 (There is also some information on bugs in the manual page and in the
  50 TODO file. Eventually more such information may move here.)
  51
  52 1:
  53   Failure in initialization files is not handled gracefully -- it's
  54   a throw to TOP-LEVEL-CATCHER, which is not caught until we enter
  55   TOPLEVEL-REPL. Code should be added to catch such THROWs even when
  56   we're not in TOPLEVEL-REPL and do *something* with them (probably
  57   complaining about an error outside TOPLEVEL-REPL, perhaps printing
  58   a BACKTRACE, then terminating execution of SBCL).
  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 STYLE-WARNING, 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 38:
 521   DEFMETHOD doesn't check the syntax of &REST argument lists properly,
 522   accepting &REST even when it's not followed by an argument name:
 523         (DEFMETHOD FOO ((X T) &REST) NIL)
 524
 525 39:
 526   On the CMU CL mailing list 26 June 2000, Douglas Crosher wrote
 527
 528   Hannu Rummukainen wrote:
 529   ...
 530   > There's something weird going on with the compilation of the attached
 531   > code.  Compiling and loading the file in a fresh lisp, then invoking
 532   > (test-it) gives
 533   Thanks for the bug report, nice to have this one fixed. It was a bug
 534   in the x86 backend, the < VOP. A fix has been committed to the main
 535   source, see the file compiler/x86/float.lisp.
 536
 537   Probably the same bug exists in SBCL.
 538
 539 40:
 540   TYPEP treats the result of UPGRADED-ARRAY-ELEMENT-TYPE as gospel,
 541   so that (TYPEP (MAKE-ARRAY 3) '(VECTOR SOMETHING-NOT-DEFINED-YET))
 542   returns (VALUES T T). Probably it should be an error instead,
 543   complaining that the type SOMETHING-NOT-DEFINED-YET is not defined.
 544
 545 41:
 546   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in
 547         (DEFTYPE INDEXOID () '(INTEGER 0 1000))
 548         (DEFUN FOO (X)
 549           (DECLARE (TYPE INDEXOID X))
 550           (THE (VALUES INDEXOID)
 551             (VALUES X)))
 552   where the implementation of the type check in function FOO
 553   includes a full call to %TYPEP. There are also some fundamental problems
 554   with the interpretation of VALUES types (inherited from CMU CL, and
 555   from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
 556   mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
 557
 558 42:
 559   The definitions of SIGCONTEXT-FLOAT-REGISTER and
 560   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
 561   supported on FreeBSD because the floating point state is not saved,
 562   but at least as of FreeBSD 4.0, the floating point state *is* saved,
 563   so they could be supported after all. Very likely
 564   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
 565
 566 43:
 567   (as discussed by Douglas Crosher on the cmucl-imp mailing list ca.
 568   Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
 569   issue with 'union, 'and, 'or etc. So even though according to the
 570   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
 571   (and now SBCL) interpret them as legal types.
 572
 573 44:
 574   ANSI specifies DEFINE-SYMBOL-MACRO, but it's not defined in SBCL.
 575   CMU CL added it ca. Aug 13, 2000, after some discussion on the mailing
 576   list, and it is probably possible to use substantially the same
 577   patches to add it to SBCL.
 578
 579 45:
 580   a slew of floating-point-related errors reported by Peter Van Eynde
 581   on July 25, 2000:
 582         a: (SQRT -9.0) fails, because SB-KERNEL::COMPLEX-SQRT is undefined.
 583            Similarly, COMPLEX-ASIN, COMPLEX-ACOS, COMPLEX-ACOSH, and others
 584            aren't found.
 585         b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT is bogus, and
 586            should probably be 1.4012985e-45. In SBCL,
 587            (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
 588            than LEAST-POSITIVE-SHORT-FLOAT. Similar problems
 589            exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
 590            and LEAST-NEGATIVE-LONG-FLOAT.
 591         c: Many expressions generate floating infinity:
 592                 (/ 1 0.0)
 593                 (/ 1 0.0d0)
 594                 (EXPT 10.0 1000)
 595                 (EXPT 10.0d0 1000)
 596            PVE's regression tests want them to raise errors. SBCL
 597            generates the infinities instead, which may or may not be
 598            conforming behavior, but then blow it by being unable to
 599            output the infinities, since support for infinities is generally
 600            broken, and in particular SB-IMPL::OUTPUT-FLOAT-INFINITY is
 601            undefined.
 602         d: (in section12.erg) various forms a la
 603                 (FLOAT 1 DOUBLE-FLOAT-EPSILON)
 604            don't give the right behavior.
 605
 606 46:
 607   type safety errors reported by Peter Van Eynde July 25, 2000:
 608         a: (COERCE (QUOTE (A B C)) (QUOTE (VECTOR * 4)))
 609            => #(A B C)
 610            In general lengths of array type specifications aren't
 611            checked by COERCE, so it fails when the spec is
 612            (VECTOR 4), (STRING 2), (SIMPLE-BIT-VECTOR 3), or whatever.
 613         b: CONCATENATE has the same problem of not checking the length
 614            of specified output array types. MAKE-SEQUENCE and MAP and
 615            MERGE also have the same problem.
 616         c: (COERCE 'AND 'FUNCTION) returns something related to
 617            (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
 618         d: ELT signals SIMPLE-ERROR if its index argument
 619            isn't a valid index for its sequence argument, but should
 620            signal TYPE-ERROR instead.
 621         e: FILE-LENGTH is supposed to signal a type error when its
 622            argument is not a stream associated with a file, but doesn't.
 623         f: (FLOAT-RADIX 2/3) should signal an error instead of
 624            returning 2.
 625         g: (LOAD "*.lsp") should signal FILE-ERROR.
 626         h: (MAKE-CONCATENATED-STREAM (MAKE-STRING-OUTPUT-STREAM))
 627            should signal TYPE-ERROR.
 628         i: MAKE-TWO-WAY-STREAM doesn't check that its arguments can
 629            be used for input and output as needed. It should fail with
 630            TYPE-ERROR when handed e.g. the results of
 631            MAKE-STRING-INPUT-STREAM or MAKE-STRING-OUTPUT-STREAM in
 632            the inappropriate positions, but doesn't.
 633         j: (PARSE-NAMESTRING (COERCE (LIST #\f #\o #\o (CODE-CHAR 0) #\4 #\8)
 634                             (QUOTE STRING)))
 635            should probably signal an error instead of making a pathname with
 636            a null byte in it.
 637         k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
 638            not a binary input stream, but instead cheerfully reads from
 639            character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
 640
 641 47:
 642   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
 643         a: (DEFCLASS FOO () (A B A)) should signal a PROGRAM-ERROR, and
 644            doesn't.
 645         b: (DEFCLASS FOO () (A B A) (:DEFAULT-INITARGS X A X B)) should
 646            signal a PROGRAM-ERROR, and doesn't.
 647         c: (DEFCLASS FOO07 NIL ((A :ALLOCATION :CLASS :ALLOCATION :CLASS))),
 648            and other DEFCLASS forms with duplicate specifications in their
 649            slots, should signal a PROGRAM-ERROR, and doesn't.
 650         d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
 651            causes a COMPILER-ERROR.
 652
 653 48:
 654   SYMBOL-MACROLET bugs reported by Peter Van Eynde July 25, 2000:
 655         a: (SYMBOL-MACROLET ((T TRUE)) ..) should probably signal
 656            PROGRAM-ERROR, but SBCL accepts it instead.
 657         b: SYMBOL-MACROLET should refuse to bind something which is
 658            declared as a global variable, signalling PROGRAM-ERROR.
 659         c: SYMBOL-MACROLET should signal PROGRAM-ERROR if something
 660            it binds is declared SPECIAL inside.
 661
 662 49:
 663   LOOP bugs reported by Peter Van Eynde July 25, 2000:
 664         a: (LOOP WITH (A B) DO (PRINT 1)) is a syntax error according to
 665            the definition of WITH clauses given in the ANSI spec, but
 666            compiles and runs happily in SBCL.
 667         b: a messy one involving package iteration:
 668 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<))))
 669 Should be: (("blah" "blah2") ("blah2"))
 670 SBCL: (("blah") ("blah2"))
 671         * (LET ((X 1)) (LOOP FOR I BY (INCF X) FROM X TO 10 COLLECT I))
 672           doesn't work -- SBCL's LOOP says BY isn't allowed in a FOR clause.
 673
 674 50:
 675   type system errors reported by Peter Van Eynde July 25, 2000:
 676         a: (SUBTYPEP 'BIGNUM 'INTEGER) => NIL, NIL
 677            but should be (VALUES T T) instead.
 678         b: (SUBTYPEP 'EXTENDED-CHAR 'CHARACTER) => NIL, NIL
 679            but should be (VALUES T T) instead.
 680         c: (SUBTYPEP '(INTEGER (0) (0)) 'NIL) dies with nested errors.
 681         d: In general, the system doesn't like '(INTEGER (0) (0)) -- it
 682            blows up at the level of SPECIFIER-TYPE with
 683            "Lower bound (0) is greater than upper bound (0)." Probably
 684            SPECIFIER-TYPE should return NIL instead.
 685         e: (TYPEP 0 '(COMPLEX (EQL 0)) fails with
 686            "Component type for Complex is not numeric: (EQL 0)."
 687            This might be easy to fix; the type system already knows
 688            that (SUBTYPEP '(EQL 0) 'NUMBER) is true.
 689         f: The type system doesn't know about the condition system,
 690            so that e.g. (TYPEP 'SIMPLE-ERROR 'ERROR)=>NIL.
 691         g: The type system isn't all that smart about relationships
 692            between hairy types, as shown in the type.erg test results,
 693            e.g. (SUBTYPEP 'CONS '(NOT ATOM)) => NIL, NIL.
 694
 695 51:
 696   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
 697         a: (PROGN
 698             (DEFGENERIC FOO02 (X))
 699             (DEFMETHOD FOO02 ((X NUMBER)) T)
 700             (LET ((M (FIND-METHOD (FUNCTION FOO02)
 701                                   NIL
 702                                   (LIST (FIND-CLASS (QUOTE NUMBER))))))
 703               (REMOVE-METHOD (FUNCTION FOO02) M)
 704               (DEFGENERIC FOO03 (X))
 705               (ADD-METHOD (FUNCTION FOO03) M)))
 706            should give an error, but SBCL allows it.
 707         b: READ should probably return READER-ERROR, not the bare
 708            arithmetic error, when input a la "1/0" or "1e1000" causes
 709            an arithmetic error.
 710         c: (BUTLAST NIL) should return NIL. (This appears to be a compiler
 711            bug, since the definition of BUTLAST, when interpreted, does
 712            give (BUTLAST NIL)=>NIL.)
 713
 714 52:
 715   It has been reported (e.g. by Peter Van Eynde) that there are
 716   several metaobject protocol "errors". (In order to fix them, we might
 717   need to document exactly what metaobject protocol specification
 718   we're following -- the current code is just inherited from PCL.)
 719
 720 53:
 721   another error from Peter Van Eynde 5 September 2000:
 722   (FORMAT NIL "~F" "FOO") should work, but instead reports an error.
 723   PVE submitted a patch to deal with this bug, but it exposes other
 724   comparably serious bugs, so I didn't apply it. It looks as though
 725   the FORMAT code needs a fair amount of rewriting in order to comply
 726   with the various details of the ANSI spec.
 727
 728 54:
 729   The implementation of #'+ returns its single argument without
 730   type checking, e.g. (+ "illegal") => "illegal".
 731
 732 55:
 733   In sbcl-0.6.7, there is no doc string for CL:PUSH, probably
 734   because it's defined with the DEFMACRO-MUNDANELY macro and something
 735   is wrong with doc string setting in that macro.
 736
 737 56:
 738   Attempting to use COMPILE on something defined by DEFMACRO fails:
 739         (DEFMACRO FOO (X) (CONS X X))
 740         (COMPILE 'FOO)
 741 Error in function C::GET-LAMBDA-TO-COMPILE:
 742    #<Closure Over Function "DEFUN (SETF MACRO-FUNCTION)" {480E21B1}> was defined in a non-null environment.
 743
 744 57:
 745   In sbcl-0.6.7, the compiler accepted a bogus declaration
 746   (TYPE INDEX LENGTH) in the definition of BUTLAST, and then died
 747   with infinite regress of errors when the BUTLAST function was
 748   executed with a LIST=NIL which would cause LENGTH to be -1.
 749   I fixed the bogus declaration, but I should come back and see
 750   whether the system's inability to recover from the bogus declaration
 751   (by signalling a TYPE-ERROR and dropping into the debugger) was
 752   a compiler problem which remains to be fixed, or one of the
 753   unrelated infinite-regress-errors problems, many related to
 754   revised signal handling, which were fixed around the same time.
 755
 756 58:
 757   (SUBTYPEP '(AND ZILCH INTEGER) 'ZILCH)
 758   => NIL, NIL
 759
 760 59:
 761   CL:*DEFAULT-PATHNAME-DEFAULTS* doesn't behave as ANSI suggests (reflecting
 762   current working directory). And there's no supported way to update
 763   or query the current working directory (a la Unix "chdir" and "pwd"),
 764   which is functionality that ILISP needs (and currently gets with low-level
 765   hacks).
 766
 767 60:
 768   The debugger LIST-LOCATIONS command doesn't work properly.