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