0.pre8.26:
[sbcl.git] / 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: "type checking of structure slots"
46   a:
47   ANSI specifies that a type mismatch in a structure slot
48   initialization value should not cause a warning.
49 WORKAROUND:
50   This one might not be fixed for a while because while we're big
51   believers in ANSI compatibility and all, (1) there's no obvious
52   simple way to do it (short of disabling all warnings for type
53   mismatches everywhere), and (2) there's a good portable
54   workaround, and (3) by their own reasoning, it looks as though
55   ANSI may have gotten it wrong. ANSI justifies this specification
56   by saying 
57     The restriction against issuing a warning for type mismatches
58     between a slot-initform and the corresponding slot's :TYPE
59     option is necessary because a slot-initform must be specified
60     in order to specify slot options; in some cases, no suitable
61     default may exist.
62   However, in SBCL (as in CMU CL or, for that matter, any compiler
63   which really understands Common Lisp types) a suitable default
64   does exist, in all cases, because the compiler understands the
65   concept of functions which never return (i.e. has return type NIL).
66   Thus, as a portable workaround, you can use a call to some
67   known-never-to-return function as the default. E.g.
68     (DEFSTRUCT FOO
69       (BAR (ERROR "missing :BAR argument")
70            :TYPE SOME-TYPE-TOO-HAIRY-TO-CONSTRUCT-AN-INSTANCE-OF))
71   or 
72     (DECLAIM (FTYPE (FUNCTION () NIL) MISSING-ARG))
73     (DEFUN REQUIRED-ARG () ; workaround for SBCL non-ANSI slot init typing
74       (ERROR "missing required argument")) 
75     (DEFSTRUCT FOO
76       (BAR (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
77       (BLETCH (REQUIRED-ARG) :TYPE TRICKY-TYPE-OF-SOME-SORT)
78       (N-REFS-SO-FAR 0 :TYPE (INTEGER 0)))
79   Such code should compile without complaint and work correctly either
80   on SBCL or on any other completely compliant Common Lisp system.
81
82   b: &AUX argument in a boa-constructor without a default value means
83      "do not initilize this slot" and does not cause type error. But
84      an error may be signalled at read time and it would be good if
85      SBCL did it.
86
87   c: Reading of not initialized slot sometimes causes SEGV.
88
89   d:
90     (declaim (optimize (safety 3) (speed 1) (space 1)))
91     (defstruct foo
92       x y)
93     (defstruct (stringwise-foo (:include foo
94                                          (x "x" :type simple-string)
95                                          (y "y" :type simple-string))))
96     (defparameter *stringwise-foo*
97       (make-stringwise-foo))
98     (setf (foo-x *stringwise-foo*) 0)
99     (defun frob-stringwise-foo (sf)
100       (aref (stringwise-foo-x sf) 0))
101     (frob-stringwise-foo *stringwise-foo*)
102   SEGV.
103
104 7:
105   The "compiling top-level form:" output ought to be condensed.
106   Perhaps any number of such consecutive lines ought to turn into a
107   single "compiling top-level forms:" line.
108
109 10:
110   The way that the compiler munges types with arguments together
111   with types with no arguments (in e.g. TYPE-EXPAND) leads to
112   weirdness visible to the user:
113         (DEFTYPE FOO () 'FIXNUM)
114         (TYPEP 11 'FOO) => T
115         (TYPEP 11 '(FOO)) => T, which seems weird
116         (TYPEP 11 'FIXNUM) => T
117         (TYPEP 11 '(FIXNUM)) signals an error, as it should
118   The situation is complicated by the presence of Common Lisp types
119   like UNSIGNED-BYTE (which can either be used in list form or alone)
120   so I'm not 100% sure that the behavior above is actually illegal.
121   But I'm 90+% sure, and the following related behavior,
122         (TYPEP 11 'AND) => T
123   treating the bare symbol AND as equivalent to '(AND), is specifically
124   forbidden (by the ANSI specification of the AND type).
125
126 11:
127   It would be nice if the
128         caught ERROR:
129           (during macroexpansion)
130   said what macroexpansion was at fault, e.g.
131         caught ERROR:
132           (during macroexpansion of IN-PACKAGE,
133           during macroexpansion of DEFFOO)
134
135 15:
136   (SUBTYPEP '(FUNCTION (T BOOLEAN) NIL)
137             '(FUNCTION (FIXNUM FIXNUM) NIL)) => T, T
138   (Also, when this is fixed, we can enable the code in PROCLAIM which 
139   checks for incompatible FTYPE redeclarations.)
140
141 19:
142   (I *think* this is a bug. It certainly seems like strange behavior. But
143   the ANSI spec is scary, dark, and deep.. -- WHN)
144     (FORMAT NIL  "~,1G" 1.4) => "1.    "
145     (FORMAT NIL "~3,1G" 1.4) => "1.    "
146
147 20:
148   from Marco Antoniotti on cmucl-imp mailing list 1 Mar 2000:
149         (defclass ccc () ())
150         (setf (find-class 'ccc1) (find-class 'ccc))
151         (defmethod zut ((c ccc1)) 123)
152   In sbcl-0.7.1.13, this gives an error, 
153         There is no class named CCC1.
154   In sbcl-0.pre8.20, this works, but prints style warnings about
155   undefined types.
156
157 27:
158   Sometimes (SB-EXT:QUIT) fails with 
159         Argh! maximum interrupt nesting depth (4096) exceeded, exiting
160         Process inferior-lisp exited abnormally with code 1
161   I haven't noticed a repeatable case of this yet.
162
163 32:
164   The printer doesn't report closures very well. This is true in 
165   CMU CL 18b as well:
166     (PRINT #'CLASS-NAME)
167   gives
168     #<Closure Over Function "DEFUN STRUCTURE-SLOT-ACCESSOR" {134D1A1}>
169   It would be nice to make closures have a settable name slot,
170   and make things like DEFSTRUCT and FLET, which create closures,
171   set helpful values into this slot.
172
173 33:
174   And as long as we're wishing, it would be awfully nice if INSPECT could
175   also report on closures, telling about the values of the bound variables.
176
177 35:
178   The compiler assumes that any time a function of declared FTYPE
179   doesn't signal an error, its arguments were of the declared type.
180   E.g. compiling and loading
181     (DECLAIM (OPTIMIZE (SAFETY 3)))
182     (DEFUN FACTORIAL (X) (GAMMA (1+ X)))
183     (DEFUN GAMMA (X) X)
184     (DECLAIM (FTYPE (FUNCTION (UNSIGNED-BYTE)) FACTORIAL))
185     (DEFUN FOO (X)
186       (COND ((> (FACTORIAL X) 1.0E6)
187              (FORMAT T "too big~%"))
188             ((INTEGERP X)
189              (FORMAT T "exactly ~S~%" (FACTORIAL X)))
190             (T
191              (FORMAT T "approximately ~S~%" (FACTORIAL X)))))
192   then executing
193     (FOO 1.5)
194   will cause the INTEGERP case to be selected, giving bogus output a la
195     exactly 2.5
196   This violates the "declarations are assertions" principle.
197   According to the ANSI spec, in the section "System Class FUNCTION",
198   this is a case of "lying to the compiler", but the lying is done
199   by the code which calls FACTORIAL with non-UNSIGNED-BYTE arguments,
200   not by the unexpectedly general definition of FACTORIAL. In any case,
201   "declarations are assertions" means that lying to the compiler should
202   cause an error to be signalled, and should not cause a bogus
203   result to be returned. Thus, the compiler should not assume
204   that arbitrary functions check their argument types. (It might
205   make sense to add another flag (CHECKED?) to DEFKNOWN to 
206   identify functions which *do* check their argument types.)
207   (Also, verify that the compiler handles declared function
208   return types as assertions.)
209
210 41:
211   TYPEP of VALUES types is sometimes implemented very inefficiently, e.g. in 
212         (DEFTYPE INDEXOID () '(INTEGER 0 1000))
213         (DEFUN FOO (X)
214           (DECLARE (TYPE INDEXOID X))
215           (THE (VALUES INDEXOID)
216             (VALUES X)))
217   where the implementation of the type check in function FOO 
218   includes a full call to %TYPEP. There are also some fundamental problems
219   with the interpretation of VALUES types (inherited from CMU CL, and
220   from the ANSI CL standard) as discussed on the cmucl-imp@cons.org
221   mailing list, e.g. in Robert Maclachlan's post of 21 Jun 2000.
222
223 42:
224   The definitions of SIGCONTEXT-FLOAT-REGISTER and
225   %SET-SIGCONTEXT-FLOAT-REGISTER in x86-vm.lisp say they're not
226   supported on FreeBSD because the floating point state is not saved,
227   but at least as of FreeBSD 4.0, the floating point state *is* saved,
228   so they could be supported after all. Very likely 
229   SIGCONTEXT-FLOATING-POINT-MODES could now be supported, too.
230
231 43:
232   (as discussed by Douglas Crosher on the cmucl-imp mailing list ca. 
233   Aug. 10, 2000): CMUCL currently interprets 'member as '(member); same
234   issue with 'union, 'and, 'or etc. So even though according to the
235   ANSI spec, bare 'MEMBER, 'AND, and 'OR are not legal types, CMUCL
236   (and now SBCL) interpret them as legal types.
237
238 45:
239   a slew of floating-point-related errors reported by Peter Van Eynde
240   on July 25, 2000:
241         b: SBCL's value for LEAST-POSITIVE-SHORT-FLOAT on the x86 is 
242            bogus, and should probably be 1.4012985e-45. In SBCL,
243            (/ LEAST-POSITIVE-SHORT-FLOAT 2) returns a number smaller
244            than LEAST-POSITIVE-SHORT-FLOAT. Similar problems 
245            exist for LEAST-NEGATIVE-SHORT-FLOAT, LEAST-POSITIVE-LONG-FLOAT,
246            and LEAST-NEGATIVE-LONG-FLOAT.
247         c: Many expressions generate floating infinity on x86/Linux:
248                 (/ 1 0.0)
249                 (/ 1 0.0d0)
250                 (EXPT 10.0 1000)
251                 (EXPT 10.0d0 1000)
252            PVE's regression tests want them to raise errors. sbcl-0.7.0.5
253            on x86/Linux generates the infinities instead. That might or
254            might not be conforming behavior, but it's also inconsistent,
255            which is almost certainly wrong. (Inconsistency: (/ 1 0.0)
256            should give the same result as (/ 1.0 0.0), but instead (/ 1 0.0)
257            generates SINGLE-FLOAT-POSITIVE-INFINITY and (/ 1.0 0.0)
258            signals an error.
259         d: (in section12.erg) various forms a la 
260                 (FLOAT 1 DOUBLE-FLOAT-EPSILON)
261            don't give the right behavior.
262
263 46:
264   type safety errors reported by Peter Van Eynde July 25, 2000:
265         c: (COERCE 'AND 'FUNCTION) returns something related to
266            (MACRO-FUNCTION 'AND), but ANSI says it should raise an error.
267         k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is 
268            not a binary input stream, but instead cheerfully reads from
269            character streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
270
271 47:
272   DEFCLASS bugs reported by Peter Van Eynde July 25, 2000:
273         d: (DEFGENERIC IF (X)) should signal a PROGRAM-ERROR, but instead
274            causes a COMPILER-ERROR.
275
276 51:
277   miscellaneous errors reported by Peter Van Eynde July 25, 2000:
278         a: (PROGN
279             (DEFGENERIC FOO02 (X))
280             (DEFMETHOD FOO02 ((X NUMBER)) T)
281             (LET ((M (FIND-METHOD (FUNCTION FOO02)
282                                   NIL
283                                   (LIST (FIND-CLASS (QUOTE NUMBER))))))
284               (REMOVE-METHOD (FUNCTION FOO02) M)
285               (DEFGENERIC FOO03 (X))
286               (ADD-METHOD (FUNCTION FOO03) M)))
287            should give an error, but SBCL allows it.
288
289 60:
290   The debugger LIST-LOCATIONS command doesn't work properly.
291
292 61:
293   Compiling and loading
294     (DEFUN FAIL (X) (THROW 'FAIL-TAG X))
295     (FAIL 12)
296   then requesting a BACKTRACE at the debugger prompt gives no information
297   about where in the user program the problem occurred.
298
299 63:
300   Paul Werkowski wrote on cmucl-imp@cons.org 2000-11-15
301     I am looking into this problem that showed up on the cmucl-help
302     list. It seems to me that the "implementation specific environment
303     hacking functions" found in pcl/walker.lisp are completely messed
304     up. The good thing is that they appear to be barely used within
305     PCL and the munged environment object is passed to cmucl only
306     in calls to macroexpand-1, which is probably why this case fails.
307   SBCL uses essentially the same code, so if the environment hacking
308   is screwed up, it affects us too.
309
310 64:
311   Using the pretty-printer from the command prompt gives funny
312   results, apparently because the pretty-printer doesn't know
313   about user's command input, including the user's carriage return
314   that the user, and therefore the pretty-printer thinks that
315   the new output block should start indented 2 or more characters
316   rightward of the correct location.
317
318 67:
319   As reported by Winton Davies on a CMU CL mailing list 2000-01-10,
320   and reported for SBCL by Martin Atzmueller 2000-10-20: (TRACE GETHASH)
321   crashes SBCL. In general tracing anything which is used in the 
322   implementation of TRACE is likely to have the same problem.
323
324 75:
325   As reported by Martin Atzmueller on sbcl-devel 26 Dec 2000,
326   ANSI says that WITH-OUTPUT-TO-STRING should have a keyword
327   :ELEMENT-TYPE, but in sbcl-0.6.9 this is not defined for
328   WITH-OUTPUT-TO-STRING.
329
330 78:
331   ANSI says in one place that type declarations can be abbreviated even
332   when the type name is not a symbol, e.g.
333     (DECLAIM ((VECTOR T) *FOOVECTOR*))
334   SBCL doesn't support this. But ANSI says in another place that this
335   isn't allowed. So it's not clear this is a bug after all. (See the
336   e-mail on cmucl-help@cons.org on 2001-01-16 and 2001-01-17 from WHN
337   and Pierre Mai.)
338
339 79:
340   as pointed out by Dan Barlow on sbcl-devel 2000-07-02:
341   The PICK-TEMPORARY-FILE-NAME utility used by LOAD-FOREIGN uses
342   an easily guessable temporary filename in a way which might open
343   applications using LOAD-FOREIGN to hijacking by malicious users
344   on the same machine. Incantations for doing this safely are
345   floating around the net in various "how to write secure programs
346   despite Unix" documents, and it would be good to (1) fix this in 
347   LOAD-FOREIGN, and (2) hunt for any other code which uses temporary
348   files and make it share the same new safe logic.
349
350   (partially alleviated in sbcl-0.7.9.32 by a fix by Matthew Danish to
351    make the temporary filename less easily guessable)
352
353 83:
354   RANDOM-INTEGER-EXTRA-BITS=10 may not be large enough for the RANDOM
355   RNG to be high quality near RANDOM-FIXNUM-MAX; it looks as though
356   the mean of the distribution can be systematically O(0.1%) wrong.
357   Just increasing R-I-E-B is probably not a good solution, since
358   it would decrease efficiency more than is probably necessary. Perhaps
359   using some sort of accept/reject method would be better.
360
361 85:
362   Internally the compiler sometimes evaluates
363     (sb-kernel:type/= (specifier-type '*) (specifier-type t))
364   (I stumbled across this when I added an
365     (assert (not (eq type1 *wild-type*)))
366   in the NAMED :SIMPLE-= type method.) '* isn't really a type, and
367   in a type context should probably be translated to T, and so it's
368   probably wrong to ask whether it's equal to the T type and then (using
369   the EQ type comparison in the NAMED :SIMPLE-= type method) return NIL.
370   (I haven't tried to investigate this bug enough to guess whether
371   there might be any user-level symptoms.)
372
373   In fact, the type system is likely to depend on this inequality not
374   holding... * is not equivalent to T in many cases, such as 
375     (VECTOR *) /= (VECTOR T).
376
377 94a: 
378   Inconsistencies between derived and declared VALUES return types for
379   DEFUN aren't checked very well. E.g. the logic which successfully
380   catches problems like
381     (declaim (ftype (function (fixnum) float) foo))
382     (defun foo (x)
383       (declare (type integer x))
384       (values x)) ; wrong return type, detected, gives warning, good!
385   fails to catch
386     (declaim (ftype (function (t) (values t t)) bar))
387     (defun bar (x)
388       (values x)) ; wrong number of return values, no warning, bad!
389   The cause of this is seems to be that (1) the internal function 
390   VALUES-TYPES-EQUAL-OR-INTERSECT used to make the check handles its
391   arguments symmetrically, and (2) when the type checking code was
392   written back when when SBCL's code was still CMU CL, the intent
393   was that this case
394     (declaim (ftype (function (t) t) bar))
395     (defun bar (x)
396       (values x x)) ; wrong number of return values; should give warning?
397   not be warned for, because a two-valued return value is considered
398   to be compatible with callers who expects a single value to be
399   returned. That intent is probably not appropriate for modern ANSI
400   Common Lisp, but fixing this might be complicated because of other
401   divergences between auld-style and new-style handling of
402   multiple-VALUES types. (Some issues related to this were discussed
403   on cmucl-imp at some length sometime in 2000.)
404
405 95:
406   The facility for dumping a running Lisp image to disk gets confused
407   when run without the PURIFY option, and creates an unnecessarily large
408   core file (apparently representing memory usage up to the previous
409   high-water mark). Moreover, when the file is loaded, it confuses the
410   GC, so that thereafter memory usage can never be reduced below that
411   level.
412
413 98:
414   In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
415   CL), out-of-line structure slot setters are horribly inefficient
416   whenever the type of the slot is declared, because out-of-line
417   structure slot setters are implemented as closures to save space,
418   so the compiler doesn't compile the type test into code, but
419   instead just saves the type in a lexical closure and interprets it
420   at runtime.
421     A proper solution involves deciding whether it's really worth
422   saving space by implementing structure slot accessors as closures.
423   (If it's not worth it, the problem vanishes automatically. If it
424   is worth it, there are hacks we could use to force type tests to
425   be compiled anyway, and even shared. E.g. we could implement
426   an EQUAL hash table mapping from types to compiled type tests, 
427   and save the appropriate compiled type test as part of each lexical
428   closure; or we could make the lexical closures be placeholders
429   which overwrite their old definition as a lexical closure with
430   a new compiled definition the first time that they're called.)
431     As a workaround for the problem, #'(SETF FOO) expressions can
432   be replaced with (EFFICIENT-SETF-FUNCTION FOO), where
433 (defmacro efficient-setf-function (place-function-name)
434   (or #+sbcl (and (sb-impl::info :function :accessor-for place-function-name)
435                   ;; a workaround for the problem, encouraging the
436                   ;; inline expansion of the structure accessor, so
437                   ;; that the compiler can optimize its type test
438                   (let ((new-value (gensym "NEW-VALUE-"))
439                         (structure-value (gensym "STRUCTURE-VALUE-")))
440                     `(lambda (,new-value ,structure-value)
441                        (setf (,place-function-name ,structure-value)
442                              ,new-value))))
443       ;; no problem, can just use the ordinary expansion
444       `(function (setf ,place-function-name))))
445
446 100:
447   There's apparently a bug in CEILING optimization which caused 
448   Douglas Crosher to patch the CMU CL version. Martin Atzmueller
449   applied the patches to SBCL and they didn't seem to cause problems
450   (as reported sbcl-devel 2001-05-04). However, since the patches
451   modify nontrivial code which was apparently written incorrectly
452   the first time around, until regression tests are written I'm not 
453   comfortable merging the patches in the CVS version of SBCL.
454
455 108:
456   (TIME (ROOM T)) reports more than 200 Mbytes consed even for
457   a clean, just-started SBCL system. And it seems to be right:
458   (ROOM T) can bring a small computer to its knees for a *long*
459   time trying to GC afterwards. Surely there's some more economical
460   way to implement (ROOM T).
461
462 117:
463   When the compiler inline expands functions, it may be that different
464   kinds of return values are generated from different code branches.
465   E.g. an inline expansion of POSITION generates integer results 
466   from one branch, and NIL results from another. When that inline
467   expansion is used in a context where only one of those results
468   is acceptable, e.g.
469     (defun foo (x)
470       (aref *a1* (position x *a2*)))
471   and the compiler can't prove that the unacceptable branch is 
472   never taken, then bogus type mismatch warnings can be generated.
473   If you need to suppress the type mismatch warnings, you can
474   suppress the inline expansion,
475     (defun foo (x)
476       #+sbcl (declare (notinline position)) ; to suppress bug 117 bogowarnings
477       (aref *a1* (position x *a2*)))
478   or, sometimes, suppress them by declaring the result to be of an
479   appropriate type,
480     (defun foo (x)
481       (aref *a1* (the integer (position x *a2*))))
482
483   This is not a new compiler problem in 0.7.0, but the new compiler
484   transforms for FIND, POSITION, FIND-IF, and POSITION-IF make it 
485   more conspicuous. If you don't need performance from these functions,
486   and the bogus warnings are a nuisance for you, you can return to
487   your pre-0.7.0 state of grace with
488     #+sbcl (declaim (notinline find position find-if position-if)) ; bug 117..
489
490 118:
491    as reported by Eric Marsden on cmucl-imp@cons.org 2001-08-14:
492      (= (FLOAT 1 DOUBLE-FLOAT-EPSILON)
493         (+ (FLOAT 1 DOUBLE-FLOAT-EPSILON) DOUBLE-FLOAT-EPSILON)) => T
494    when of course it should be NIL. (He says it only fails for X86,
495    not SPARC; dunno about Alpha.)
496
497    Also, "the same problem exists for LONG-FLOAT-EPSILON,
498    DOUBLE-FLOAT-NEGATIVE-EPSILON, LONG-FLOAT-NEGATIVE-EPSILON (though
499    for the -negative- the + is replaced by a - in the test)."
500
501    Raymond Toy comments that this is tricky on the X86 since its FPU
502    uses 80-bit precision internally.
503
504 120b:
505    Even in sbcl-0.pre7.x, which is supposed to be free of the old
506    non-ANSI behavior of treating the function return type inferred
507    from the current function definition as a declaration of the
508    return type from any function of that name, the return type of NIL
509    is attached to FOO in 120a above, and used to optimize code which
510    calls FOO. 
511
512 124:
513    As of version 0.pre7.14, SBCL's implementation of MACROLET makes
514    the entire lexical environment at the point of MACROLET available
515    in the bodies of the macroexpander functions. In particular, it
516    allows the function bodies (which run at compile time) to try to
517    access lexical variables (which are only defined at runtime).
518    It doesn't even issue a warning, which is bad.
519
520    The SBCL behavior arguably conforms to the ANSI spec (since the
521    spec says that the behavior is undefined, ergo anything conforms).
522    However, it would be better to issue a compile-time error.
523    Unfortunately I (WHN) don't see any simple way to detect this
524    condition in order to issue such an error, so for the meantime
525    SBCL just does this weird broken "conforming" thing.
526
527    The ANSI standard says, in the definition of the special operator
528    MACROLET,
529        The macro-expansion functions defined by MACROLET are defined
530        in the lexical environment in which the MACROLET form appears.
531        Declarations and MACROLET and SYMBOL-MACROLET definitions affect
532        the local macro definitions in a MACROLET, but the consequences
533        are undefined if the local macro definitions reference any
534        local variable or function bindings that are visible in that
535        lexical environment.
536    Then it seems to contradict itself by giving the example
537         (defun foo (x flag)
538            (macrolet ((fudge (z)
539                          ;The parameters x and flag are not accessible
540                          ; at this point; a reference to flag would be to
541                          ; the global variable of that name.
542                          ` (if flag (* ,z ,z) ,z)))
543             ;The parameters x and flag are accessible here.
544              (+ x
545                 (fudge x)
546                 (fudge (+ x 1)))))
547    The comment "a reference to flag would be to the global variable
548    of the same name" sounds like good behavior for the system to have.
549    but actual specification quoted above says that the actual behavior
550    is undefined.
551
552    (Since 0.7.8.23 macroexpanders are defined in a restricted version
553    of the lexical environment, containing no lexical variables and
554    functions, which seems to conform to ANSI and CLtL2, but signalling
555    a STYLE-WARNING for references to variables similar to locals might
556    be a good thing.)
557
558 125:
559    (as reported by Gabe Garza on cmucl-help 2001-09-21)
560         (defvar *tmp* 3)
561         (defun test-pred (x y)
562           (eq x y))
563         (defun test-case ()
564           (let* ((x *tmp*)
565                  (func (lambda () x)))
566             (print (eq func func))
567             (print (test-pred func func))
568             (delete func (list func))))
569    Now calling (TEST-CASE) gives output
570      NIL
571      NIL
572      (#<FUNCTION {500A9EF9}>)
573    Evidently Python thinks of the lambda as a code transformation so
574    much that it forgets that it's also an object.
575
576 135:
577   Ideally, uninterning a symbol would allow it, and its associated
578   FDEFINITION and PROCLAIM data, to be reclaimed by the GC. However,
579   at least as of sbcl-0.7.0, this isn't the case. Information about
580   FDEFINITIONs and PROCLAIMed properties is stored in globaldb.lisp
581   essentially in ordinary (non-weak) hash tables keyed by symbols.
582   Thus, once a system has an entry in this system, it tends to live
583   forever, even when it is uninterned and all other references to it
584   are lost.
585
586 141: "pretty printing and backquote"
587   a.
588     * '``(FOO ,@',@S)
589     ``(FOO SB-IMPL::BACKQ-COMMA-AT S)
590
591   b.
592     * (write '`(, .ala.) :readably t :pretty t)
593     `(,.ALA.)
594
595   (note the space between the comma and the point)
596
597 143:
598   (reported by Jesse Bouwman 2001-10-24 through the unfortunately
599   prominent SourceForge web/db bug tracking system, which is 
600   unfortunately not a reliable way to get a timely response from
601   the SBCL maintainers)
602       In the course of trying to build a test case for an 
603     application error, I encountered this behavior: 
604       If you start up sbcl, and then lay on CTRL-C for a 
605     minute or two, the lisp process will eventually say: 
606          %PRIMITIVE HALT called; the party is over. 
607     and throw you into the monitor. If I start up lisp, 
608     attach to the process with strace, and then do the same 
609     (abusive) thing, I get instead: 
610          access failure in heap page not marked as write-protected 
611     and the monitor again. I don't know enough to have the 
612     faintest idea of what is going on here. 
613       This is with sbcl 6.12, uname -a reports: 
614          Linux prep 2.2.19 #4 SMP Tue Apr 24 13:59:52 CDT 2001 i686 unknown 
615   I (WHN) have verified that the same thing occurs on sbcl-0.pre7.141
616   under OpenBSD 2.9 on my X86 laptop. Do be patient when you try it:
617   it took more than two minutes (but less than five) for me.
618
619 144: 
620   (This was once known as IR1-4, but it lived on even after the
621   IR1 interpreter went to the big bit bucket in the sky.)
622   The system accepts DECLAIM in most places where DECLARE would be 
623   accepted, without even issuing a warning. ANSI allows this, but since
624   it's fairly easy to mistype DECLAIM instead of DECLARE, and the
625   meaning is rather different, and it's unlikely that the user
626   has a good reason for doing DECLAIM not at top level, it would be 
627   good to issue a STYLE-WARNING when this happens. A possible
628   fix would be to issue STYLE-WARNINGs for DECLAIMs not at top level,
629   or perhaps to issue STYLE-WARNINGs for any EVAL-WHEN not at top level.
630   [This is considered an IR1-interpreter-related bug because until
631   EVAL-WHEN is rewritten, which won't happen until after the IR1
632   interpreter is gone, the system's notion of what's a top-level form
633   and what's not will remain too confused to fix this problem.]
634
635 145:
636   ANSI allows types `(COMPLEX ,FOO) to use very hairy values for
637   FOO, e.g. (COMPLEX (AND REAL (SATISFIES ODDP))). The old CMU CL
638   COMPLEX implementation didn't deal with this, and hasn't been
639   upgraded to do so. (This doesn't seem to be a high priority
640   conformance problem, since seems hard to construct useful code
641   where it matters.)
642
643 146:
644   Floating point errors are reported poorly. E.g. on x86 OpenBSD
645   with sbcl-0.7.1, 
646         * (expt 2.0 12777)
647         debugger invoked on condition of type SB-KERNEL:FLOATING-POINT-EXCEPTION:
648           An arithmetic error SB-KERNEL:FLOATING-POINT-EXCEPTION was signalled.
649         No traps are enabled? How can this be?
650   It should be possible to be much more specific (overflow, division
651   by zero, etc.) and of course the "How can this be?" should be fixable.
652
653   See also bugs #45.c and #183
654
655 148:
656   In sbcl-0.7.1.3 on x86, COMPILE-FILE on the file
657     (in-package :cl-user)
658     (defvar *thing*)
659     (defvar *zoom*)
660     (defstruct foo bar bletch)
661     (defun %zeep ()
662       (labels ((kidify1 (kid)
663                  )
664                (kid-frob (kid)
665                  (if *thing*
666                     (setf sweptm
667                            (m+ (frobnicate kid)
668                                      sweptm))
669                     (kidify1 kid))))
670       (declare (inline kid-frob))
671       (map nil
672            #'kid-frob
673            (the simple-vector (foo-bar perd)))))
674   fails with
675     debugger invoked on condition of type TYPE-ERROR:
676       The value NIL is not of type SB-C::NODE.
677   The location of this failure has moved around as various related
678   issues were cleaned up. As of sbcl-0.7.1.9, it occurs in
679   NODE-BLOCK called by LAMBDA-COMPONENT called by IR2-CONVERT-CLOSURE.
680
681   (Python LET-converts KIDIFY1 into KID-FROB, then tries to inline
682   expand KID-FROB into %ZEEP. Having partially done it, it sees a call
683   of KIDIFY1, which already does not exist. So it gives up on
684   expansion, leaving garbage consisting of infinished blocks of the
685   partially converted function.)
686
687   (due to reordering of the compiler this example is compiled
688   successfully by 0.7.14, but the bug probably remains)
689
690 162:
691   (reported by Robert E. Brown 2002-04-16) 
692   When a function is called with too few arguments, causing the
693   debugger to be entered, the uninitialized slots in the bad call frame 
694   seem to cause GCish problems, being interpreted as tagged data even
695   though they're not. In particular, executing ROOM in the
696   debugger at that point causes AVER failures:
697     * (machine-type)
698     "X86"
699     * (lisp-implementation-version)
700     "0.7.2.12"
701     * (typep 10)
702     ...
703     0] (room)
704     ...
705     failed AVER: "(SAP= CURRENT END)"
706   (Christophe Rhodes reports that this doesn't occur on the SPARC, which
707   isn't too surprising since there are many differences in stack
708   implementation and GC conservatism between the X86 and other ports.)
709
710 167:
711   In sbcl-0.7.3.11, compiling the (illegal) code 
712     (in-package :cl-user)
713     (defmethod prove ((uustk uustk))
714       (zap ((frob () nil))
715         (frob)))
716   gives the (not terribly clear) error message
717     ; caught ERROR:
718     ;   (during macroexpansion of (DEFMETHOD PROVE ...))
719     ; can't get template for (FROB NIL NIL)
720   The problem seems to be that the code walker used by the DEFMETHOD
721   macro is unhappy with the illegal syntax in the method body, and
722   is giving an unclear error message.
723
724 173:
725   The compiler sometimes tries to constant-fold expressions before
726   it checks to see whether they can be reached. This can lead to 
727   bogus warnings about errors in the constant folding, e.g. in code
728   like 
729     (WHEN X
730       (WRITE-STRING (> X 0) "+" "0"))
731   compiled in a context where the compiler can prove that X is NIL,
732   and the compiler complains that (> X 0) causes a type error because
733   NIL isn't a valid argument to #'>. Until sbcl-0.7.4.10 or so this
734   caused a full WARNING, which made the bug really annoying because then 
735   COMPILE and COMPILE-FILE returned FAILURE-P=T for perfectly legal
736   code. Since then the warning has been downgraded to STYLE-WARNING, 
737   so it's still a bug but at least it's a little less annoying.
738
739 183: "IEEE floating point issues"
740   Even where floating point handling is being dealt with relatively
741   well (as of sbcl-0.7.5, on sparc/sunos and alpha; see bug #146), the
742   accrued-exceptions and current-exceptions part of the fp control
743   word don't seem to bear much relation to reality. E.g. on
744   SPARC/SunOS:
745   * (/ 1.0 0.0)
746
747   debugger invoked on condition of type DIVISION-BY-ZERO:
748     arithmetic error DIVISION-BY-ZERO signalled
749   0] (sb-vm::get-floating-point-modes)
750
751   (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
752           :ROUNDING-MODE :NEAREST
753           :CURRENT-EXCEPTIONS NIL
754           :ACCRUED-EXCEPTIONS (:INEXACT)
755           :FAST-MODE NIL)
756   0] abort
757   * (sb-vm::get-floating-point-modes)
758   (:TRAPS (:OVERFLOW :INVALID :DIVIDE-BY-ZERO)
759           :ROUNDING-MODE :NEAREST
760           :CURRENT-EXCEPTIONS (:INEXACT)
761           :ACCRUED-EXCEPTIONS (:INEXACT)
762           :FAST-MODE NIL)
763
764 187: "type inference confusion around DEFTRANSFORM time"
765   (reported even more verbosely on sbcl-devel 2002-06-28 as "strange
766   bug in DEFTRANSFORM")
767   After the file below is compiled and loaded in sbcl-0.7.5, executing
768     (TCX (MAKE-ARRAY 4 :FILL-POINTER 2) 0)
769   at the REPL returns an adjustable vector, which is wrong. Presumably
770   somehow the DERIVE-TYPE information for the output values of %WAD is
771   being mispropagated as a type constraint on the input values of %WAD,
772   and so causing the type test to be optimized away. It's unclear how
773   hand-expanding the DEFTRANSFORM would change this, but it suggests
774   the DEFTRANSFORM machinery (or at least the way DEFTRANSFORMs are
775   invoked at a particular phase) is involved.
776     (cl:in-package :sb-c)
777     (eval-when (:compile-toplevel)
778     ;;; standin for %DATA-VECTOR-AND-INDEX
779     (defknown %dvai (array index) 
780       (values t t) 
781       (foldable flushable))
782     (deftransform %dvai ((array index)
783                          (vector t)
784                          *
785                          :important t)
786       (let* ((atype (continuation-type array))
787              (eltype (array-type-specialized-element-type atype)))
788         (when (eq eltype *wild-type*)
789           (give-up-ir1-transform
790            "specialized array element type not known at compile-time"))
791         (when (not (array-type-complexp atype))
792           (give-up-ir1-transform "SIMPLE array!"))
793         `(if (array-header-p array)
794              (%wad array index nil)
795              (values array index))))
796     ;;; standin for %WITH-ARRAY-DATA
797     (defknown %wad (array index (or index null))
798       (values (simple-array * (*)) index index index)
799       (foldable flushable))
800     ;;; (Commenting out this optimizer causes the bug to go away.)
801     (defoptimizer (%wad derive-type) ((array start end))
802       (let ((atype (continuation-type array)))
803         (when (array-type-p atype)
804           (values-specifier-type
805            `(values (simple-array ,(type-specifier
806                                     (array-type-specialized-element-type atype))
807                                   (*))
808                     index index index)))))
809     ) ; EVAL-WHEN
810     (defun %wad (array start end)
811       (format t "~&in %WAD~%")
812       (%with-array-data array start end))
813     (cl:in-package :cl-user)
814     (defun tcx (v i)
815       (declare (type (vector t) v))
816       (declare (notinline sb-kernel::%with-array-data))
817       ;; (Hand-expending DEFTRANSFORM %DVAI here also causes the bug to
818       ;; go away.) 
819       (sb-c::%dvai v i))
820
821 188: "compiler performance fiasco involving type inference and UNION-TYPE"
822   (In sbcl-0.7.6.10, DEFTRANSFORM CONCATENATE was commented out until this
823   bug could be fixed properly, so you won't see the bug unless you restore
824   the DEFTRANSFORM by hand.) In sbcl-0.7.5.11 on a 700 MHz Pentium III, 
825     (time (compile
826            nil
827            '(lambda ()
828               (declare (optimize (safety 3)))
829               (declare (optimize (compilation-speed 2)))
830               (declare (optimize (speed 1) (debug 1) (space 1)))
831               (let ((fn "if-this-file-exists-the-universe-is-strange"))
832                 (load fn :if-does-not-exist nil)
833                 (load (concatenate 'string fn ".lisp") :if-does-not-exist nil)
834                 (load (concatenate 'string fn ".fasl") :if-does-not-exist nil)
835                 (load (concatenate 'string fn ".misc-garbage")
836                       :if-does-not-exist nil)))))
837   reports  
838                  134.552 seconds of real time
839                  133.35156 seconds of user run time
840                  0.03125 seconds of system run time
841                    [Run times include 2.787 seconds GC run time.]
842                  0 page faults and
843                  246883368 bytes consed.
844   BACKTRACE from Ctrl-C in the compilation shows that the compiler is
845   thinking about type relationships involving types like
846      #<UNION-TYPE
847        (OR (INTEGER 576 576)
848            (INTEGER 1192 1192)
849            (INTEGER 2536 2536)
850            (INTEGER 1816 1816)
851            (INTEGER 2752 2752)
852            (INTEGER 1600 1600)
853            (INTEGER 2640 2640)
854            (INTEGER 1808 1808)
855            (INTEGER 1296 1296)
856            ...)>)[:EXTERNAL]
857
858 190: "PPC/Linux pipe? buffer? bug"
859   In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
860   on the PPC/Linux platform, waiting for a zombie env process.  This
861   is a classic symptom of buffer filling and deadlock, but it seems
862   only sporadically reproducible.
863
864 191: "Miscellaneous PCL deficiencies"
865   (reported by Alexey Dejneka sbcl-devel 2002-08-04)
866   a. DEFCLASS does not inform the compiler about generated
867      functions. Compiling a file with
868        (DEFCLASS A-CLASS ()
869          ((A-CLASS-X)))
870        (DEFUN A-CLASS-X (A)
871          (WITH-SLOTS (A-CLASS-X) A
872            A-CLASS-X))
873      results in a STYLE-WARNING:
874        undefined-function 
875          SB-SLOT-ACCESSOR-NAME::|COMMON-LISP-USER A-CLASS-X slot READER|
876
877      APD's fix for this was checked in to sbcl-0.7.6.20, but Pierre
878      Mai points out that the declamation of functions is in fact
879      incorrect in some cases (most notably for structure
880      classes).  This means that at present erroneous attempts to use
881      WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
882      won't get the corresponding STYLE-WARNING.
883   c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
884      lists and &KEY arguments) do not signal errors when they should.
885
886 192: "Python treats free type declarations as promises."
887   b. What seemed like the same fundamental problem as bug 192a, but
888      was not fixed by the same (APD "more strict type checking
889      sbcl-devel 2002-08-97) patch:
890      (DOTIMES (I ...) (DOTIMES (J ...) (DECLARE ...) ...)):
891        (declaim (optimize (speed 1) (safety 3)))
892        (defun trust-assertion (i)
893          (dotimes (j i)
894            (declare (type (mod 4) i)) ; when commented out, behavior changes!
895            (unless (< i 5)
896              (print j))))
897        (trust-assertion 6) ; prints nothing unless DECLARE is commented out
898
899      (see bug 203)
900
901   c. (defun foo (x y)
902        (locally (declare (type fixnum x y))
903          (+ x (* 2 y))))
904      (foo 1.1 2) => 5.1
905
906 194: "no error from (THE REAL '(1 2 3)) in some cases"
907   fixed parts:
908     a. In sbcl-0.7.7.9, 
909          (multiple-value-prog1 (progn (the real '(1 2 3))))
910        returns (1 2 3) instead of signalling an error. This was fixed by 
911        APD's "more strict type checking patch", but although the fixed
912        code (in sbcl-0.7.7.19) works (signals TYPE-ERROR) interactively,
913        it's difficult to write a regression test for it, because
914        (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
915        still returns (1 2 3).
916   still-broken parts:
917     b. (IGNORE-ERRORS (MULTIPLE-VALUE-PROG1 (PROGN (THE REAL '(1 2 3)))))
918        returns (1 2 3). (As above, this shows up when writing regression
919        tests for fixed-ness of part a.)
920     c. Also in sbcl-0.7.7.9, (IGNORE-ERRORS (THE REAL '(1 2 3))) => (1 2 3).
921     d. At the REPL,
922          (null (ignore-errors
923            (let ((arg1 1)
924                  (arg2 (identity (the real #(1 2 3)))))
925              (if (< arg1 arg2) arg1 arg2))))
926            => T
927       but putting the same expression inside (DEFUN FOO () ...),
928       (FOO) => NIL.
929   notes:
930     * Actually this entry is probably multiple bugs, as
931       Alexey Dejneka commented on sbcl-devel 2002-09-03:)
932         I don't think that placing these two bugs in one entry is
933         a good idea: they have different explanations. The second
934         (min 1 nil) is caused by flushing of unused code--IDENTITY
935         can do nothing with it. So it is really bug 122. The first
936         (min nil) is due to M-V-PROG1: substituting a continuation
937         for the result, it forgets about type assertion. The purpose
938         of IDENTITY is to save the restricted continuation from
939         inaccurate transformations.
940     * Alexey Dejneka pointed out that
941         (IGNORE-ERRORS (IDENTITY (THE REAL '(1 2 3))))
942       and
943         (IGNORE-ERRORS (VALUES (THE REAL '(1 2 3))))
944       work as they should.
945
946 201: "Incautious type inference from compound CONS types"
947   (reported by APD sbcl-devel 2002-09-17)
948     (DEFUN FOO (X)
949       (LET ((Y (CAR (THE (CONS INTEGER *) X))))
950         (SETF (CAR X) NIL)
951         (FORMAT NIL "~S IS ~S, Y = ~S"
952                 (CAR X)
953                 (TYPECASE (CAR X)
954                   (INTEGER 'INTEGER)
955                   (T '(NOT INTEGER)))
956                 Y)))
957
958     (FOO ' (1 . 2)) => "NIL IS INTEGER, Y = 1"
959
960 203:
961   Compiler does not check THEs on unused values, e.g. in
962
963     (progn (the real (list 1)) t)
964
965   This situation may appear during optimizing away degenerate cases of
966   certain functions: see bug 192b.
967
968 205: "environment issues in cross compiler"
969   (These bugs have no impact on user code, but should be fixed or
970   documented.)
971   a. Macroexpanders introduced with MACROLET are defined in the null
972      lexical environment.
973   b. The body of (EVAL-WHEN (:COMPILE-TOPLEVEL) ...) is evaluated in
974      the null lexical environment.
975   c. The cross-compiler cannot inline functions defined in a non-null
976      lexical environment.
977
978 206: ":SB-FLUID feature broken"
979   (reported by Antonio Martinez-Shotton sbcl-devel 2002-10-07)
980   Enabling :SB-FLUID in the target-features list in sbcl-0.7.8 breaks
981   the build.
982
983 207: "poorly distributed SXHASH results for compound data"
984   SBCL's SXHASH could probably try a little harder. ANSI: "the
985   intent is that an implementation should make a good-faith
986   effort to produce hash-codes that are well distributed
987   within the range of non-negative fixnums". But
988         (let ((hits (make-hash-table)))
989           (dotimes (i 16)
990             (dotimes (j 16)
991               (let* ((ij (cons i j))
992                      (newlist (push ij (gethash (sxhash ij) hits))))
993                 (when (cdr newlist)
994                   (format t "~&collision: ~S~%" newlist))))))
995   reports lots of collisions in sbcl-0.7.8. A stronger MIX function
996   would be an obvious way of fix. Maybe it would be acceptably efficient
997   to redo MIX using a lookup into a 256-entry s-box containing
998   29-bit pseudorandom numbers?
999
1000 208: "package confusion in PCL handling of structure slot handlers"
1001   In sbcl-0.7.8 compiling and loading
1002         (in-package :cl)
1003         (defstruct foo (slot (error "missing")) :type list :read-only t)
1004         (defmethod print-object ((foo foo) stream) (print nil stream))
1005   causes CERROR "attempting to modify a symbol in the COMMON-LISP
1006   package: FOO-SLOT". (This is fairly bad code, but still it's hard
1007   to see that it should cause symbols to be interned in the CL package.)
1008
1009 211: "keywords processing"
1010   a. :ALLOW-OTHER-KEYS T should allow a function to receive an odd
1011      number of keyword arguments.
1012   e. Compiling
1013
1014       (flet ((foo (&key y) (list y)))
1015         (list (foo :y 1 :y 2)))
1016
1017      issues confusing message
1018
1019        ; in: LAMBDA NIL
1020        ;     (FOO :Y 1 :Y 2)
1021        ;
1022        ; caught STYLE-WARNING:
1023        ;   The variable #:G15 is defined but never used.
1024
1025 212: "Sequence functions and circular arguments"
1026   COERCE, MERGE and CONCATENATE go into an infinite loop when given
1027   circular arguments; it would be good for the user if they could be
1028   given an error instead (ANSI 17.1.1 allows this behaviour on the part
1029   of the implementation, as conforming code cannot give non-proper
1030   sequences to these functions.  MAP also has this problem (and
1031   solution), though arguably the convenience of being able to do
1032     (MAP 'LIST '+ FOO '#1=(1 . #1#))
1033   might be classed as more important (though signalling an error when
1034   all of the arguments are circular is probably desireable).
1035
1036 213: "Sequence functions and type checking"
1037   a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
1038      various complicated, though recognizeable, CONS types [e.g.
1039        (CONS * (CONS * NULL))
1040      which according to ANSI should be recognized] (and, in SAFETY 3
1041      code, should return a list of LENGTH 2 or signal an error)
1042   b. MAP, when given a type argument that is SUBTYPEP LIST, does not
1043      check that it will return a sequence of the given type.  Fixing
1044      it along the same lines as the others (cf. work done around
1045      sbcl-0.7.8.45) is possible, but doing so efficiently didn't look
1046      entirely straightforward.
1047   c. All of these functions will silently accept a type of the form
1048        (CONS INTEGER *)
1049      whether or not the return value is of this type.  This is
1050      probably permitted by ANSI (see "Exceptional Situations" under
1051      ANSI MAKE-SEQUENCE), but the DERIVE-TYPE mechanism does not
1052      know about this escape clause, so code of the form
1053        (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2)))
1054      can erroneously return T.
1055
1056 214:
1057   SBCL 0.6.12.43 fails to compile
1058
1059   (locally
1060       (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
1061     (flet ((foo (&key (x :vx x-p)) (list x x-p)))
1062       (foo 1 2)))
1063
1064   or a more simple example:
1065
1066   (locally
1067       (declare (optimize (inhibit-warnings 0) (compilation-speed 2)))
1068     (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x))))
1069
1070 215: ":TEST-NOT handling by functions"
1071   a. FIND and POSITION currently signal errors when given non-NIL for
1072      both their :TEST and (deprecated) :TEST-NOT arguments, but by
1073      ANSI 17.2 "the consequences are unspecified", which by ANSI 1.4.2
1074      means that the effect is "unpredictable but harmless".  It's not
1075      clear what that actually means; it may preclude conforming
1076      implementations from signalling errors.
1077   b. COUNT, REMOVE and the like give priority to a :TEST-NOT argument
1078      when conflict occurs.  As a quality of implementation issue, it
1079      might be preferable to treat :TEST and :TEST-NOT as being in some
1080      sense the same &KEY, and effectively take the first test function in
1081      the argument list.
1082   c. Again, a quality of implementation issue: it would be good to issue a
1083      STYLE-WARNING at compile-time for calls with :TEST-NOT, and a
1084      WARNING for calls with both :TEST and :TEST-NOT; possibly this
1085      latter should be WARNed about at execute-time too.
1086
1087 216: "debugger confused by frames with invalid number of arguments"
1088   In sbcl-0.7.8.51, executing e.g. (VECTOR-PUSH-EXTEND T), BACKTRACE, Q
1089   leaves the system confused, enough so that (QUIT) no longer works.
1090   It's as though the process of working with the uninitialized slot in
1091   the bad VECTOR-PUSH-EXTEND frame causes GC problems, though that may
1092   not be the actual problem. (CMU CL 18c doesn't have problems with this.)
1093
1094 217: "Bad type operations with FUNCTION types"
1095   In sbcl.0.7.7:
1096
1097     * (values-type-union (specifier-type '(function (base-char)))
1098                          (specifier-type '(function (integer))))
1099
1100     #<FUN-TYPE (FUNCTION (BASE-CHAR) *)>
1101
1102   It causes insertion of wrong type assertions into generated
1103   code. E.g.
1104
1105     (defun foo (x s)
1106       (let ((f (etypecase x
1107                  (character #'write-char)
1108                  (integer #'write-byte))))
1109         (funcall f x s)
1110         (etypecase x
1111           (character (write-char x s))
1112           (integer (write-byte x s)))))
1113
1114    Then (FOO #\1 *STANDARD-OUTPUT*) signals type error.
1115
1116   (In 0.7.9.1 the result type is (FUNCTION * *), so Python does not
1117   produce invalid code, but type checking is not accurate. Similar
1118   problems exist with VALUES-TYPE-INTERSECTION.)
1119
1120 218: "VALUES type specifier semantics"
1121   (THE (VALUES ...) ...) in safe code discards extra values.
1122
1123   (defun test (x y) (the (values integer) (truncate x y)))
1124   (test 10 4) => 2
1125
1126 220:
1127   Sbcl 0.7.9 fails to compile
1128
1129   (multiple-value-call #'list
1130     (the integer (helper))
1131     nil)
1132
1133   Type check for INTEGER, the result of which serves as the first
1134   argument of M-V-C, is inserted after evaluation of NIL. So arguments
1135   of M-V-C are pushed in the wrong order. As a temporary workaround
1136   type checking was disabled for M-V-Cs in 0.7.9.13. A better solution
1137   would be to put the check between evaluation of arguments, but it
1138   could be tricky to check result types of PROG1, IF etc.
1139
1140 229:
1141   (subtypep 'function '(function)) => nil, t.
1142
1143 233: bugs in constraint propagation
1144   a.
1145   (defun foo (x)
1146     (declare (optimize (speed 2) (safety 3)))
1147     (let ((y 0d0))
1148       (values
1149        (the double-float x)
1150        (setq y (+ x 1d0))
1151        (setq x 3d0)
1152        (quux y (+ y 2d0) (* y 3d0)))))
1153   (foo 4) => segmentation violation
1154
1155   (see usage of CONTINUATION-ASSERTED-TYPE in USE-RESULT-CONSTRAINTS)
1156   (see also bug 236)
1157
1158   b.
1159   (declaim (optimize (speed 2) (safety 3)))
1160   (defun foo (x y)
1161     (if (typep (prog1 x (setq x y)) 'double-float)
1162         (+ x 1d0)
1163         (+ x 2)))
1164   (foo 1d0 5) => segmentation violation
1165
1166 235: "type system and inline expansion"
1167   a.
1168   (declaim (ftype (function (cons) number) acc))
1169   (declaim (inline acc))
1170   (defun acc (c)
1171     (the number (car c)))
1172
1173   (defun foo (x y)
1174     (values (locally (declare (optimize (safety 0)))
1175               (acc x))
1176             (locally (declare (optimize (safety 3)))
1177               (acc y))))
1178
1179   (foo '(nil) '(t)) => NIL, T.
1180
1181   b. (reported by brown on #lisp 2003-01-21)
1182
1183     (defun find-it (x)
1184       (declare (optimize (speed 3) (safety 0)))
1185       (declare (notinline mapcar))
1186       (let ((z (mapcar #'car x)))
1187         (find 'foobar z)))
1188
1189   Without (DECLARE (NOTINLINE MAPCAR)), Python cannot derive that Z is
1190   LIST.
1191
1192 236: "THE semantics is broken"
1193
1194   (defun foo (a f)
1195     (declare (optimize (speed 2) (safety 0)))
1196     (+ 1d0
1197        (the double-float
1198          (multiple-value-prog1
1199              (svref a 0)
1200            (unless f (return-from foo 0))))))
1201
1202   (foo #(4) nil) => SEGV
1203
1204   VOP selection thinks that in unsafe code result type assertions
1205   should be valid immediately. (See also bug 233a.)
1206
1207   The similar problem exists for TRULY-THE.
1208
1209 237: "Environment arguments to type functions"
1210   a. Functions SUBTYPEP, TYPEP, UPGRADED-ARRAY-ELEMENT-TYPE, and 
1211      UPGRADED-COMPLEX-PART-TYPE now have an optional environment
1212      argument, but they ignore it completely.  This is almost 
1213      certainly not correct.
1214   b. Also, the compiler's optimizers for TYPEP have not been informed
1215      about the new argument; consequently, they will not transform
1216      calls of the form (TYPEP 1 'INTEGER NIL), even though this is
1217      just as optimizeable as (TYPEP 1 'INTEGER).
1218
1219 238: "REPL compiler overenthusiasm for CLOS code"
1220   From the REPL,
1221     * (defclass foo () ())
1222     * (defmethod bar ((x foo) (foo foo)) (call-next-method))
1223   causes approximately 100 lines of code deletion notes.  Some
1224   discussion on this issue happened under the title 'Three "interesting"
1225   bugs in PCL', resulting in a fix for this oververbosity from the
1226   compiler proper; however, the problem persists in the interactor
1227   because the notion of original source is not preserved: for the
1228   compiler, the original source of the above expression is (DEFMETHOD
1229   BAR ((X FOO) (FOO FOO)) (CALL-NEXT-METHOD)), while by the time the
1230   compiler gets its hands on the code needing compilation from the REPL,
1231   it has been macroexpanded several times.
1232
1233 241: "DEFCLASS mysteriously remembers uninterned accessor names."
1234   (from tonyms on #lisp IRC 2003-02-25)
1235   In sbcl-0.7.12.55, typing
1236     (defclass foo () ((bar :accessor foo-bar)))
1237     (profile foo-bar)
1238     (unintern 'foo-bar)
1239     (defclass foo () ((bar :accessor foo-bar)))
1240   gives the error message
1241     "#:FOO-BAR already names an ordinary function or a macro."
1242   So it's somehow checking the uninterned old accessor name instead
1243   of the new requested accessor name, which seems broken to me (WHN).
1244
1245 242: "WRITE-SEQUENCE suboptimality"
1246   (observed from clx performance)
1247   In sbcl-0.7.13, WRITE-SEQUENCE of a sequence of type 
1248   (SIMPLE-ARRAY (UNSIGNED-BYTE 8) (*)) on a stream with element-type
1249   (UNSIGNED-BYTE 8) will write to the stream one byte at a time,
1250   rather than writing the sequence in one go, leading to severe
1251   performance degradation.
1252
1253 DEFUNCT CATEGORIES OF BUGS
1254   IR1-#:
1255     These labels were used for bugs related to the old IR1 interpreter.
1256     The # values reached 6 before the category was closed down.