(FLOAT 1 DOUBLE-FLOAT-EPSILON)
don't give the right behavior.
-46:
- type safety errors reported by Peter Van Eynde July 25, 2000:
- k: READ-BYTE is supposed to signal TYPE-ERROR when its argument is
- not a binary input stream, but instead cheerfully reads from
- string-input streams, e.g. (MAKE-STRING-INPUT-STREAM "abc").
- [ Bug was reported as "from character streams", but in 0.8.3.10 we
- get correct behaviour from (WITH-OPEN-FILE (i "/dev/zero") (READ-BYTE i)) ]
-
-
60:
The debugger LIST-LOCATIONS command doesn't work properly.
(How should it work properly?)
GC, so that thereafter memory usage can never be reduced below that
level.
+ (As of 0.8.7.3 it's likely that the latter half of this bug is fixed.
+ The interaction between gencgc and the variables used by
+ save-lisp-and-die is still nonoptimal, though, so no respite from
+ big core files yet)
+
98:
In sbcl-0.6.11.41 (and in all earlier SBCL, and in CMU
CL), out-of-line structure slot setters are horribly inefficient
time trying to GC afterwards. Surely there's some more economical
way to implement (ROOM T).
+ Daniel Barlow doesn't know what fixed this, but observes that it
+ doesn't seem to be the case in 0.8.7.3 any more. Instead, (ROOM T)
+ in a fresh SBCL causes
+
+ debugger invoked on a SB-INT:BUG in thread 5911:
+ failed AVER: "(SAP= CURRENT END)"
+
+ unless a GC has happened beforehand.
+
117:
When the compiler inline expands functions, it may be that different
kinds of return values are generated from different code branches.
Raymond Toy comments that this is tricky on the X86 since its FPU
uses 80-bit precision internally.
-120b:
- Even in sbcl-0.pre7.x, which is supposed to be free of the old
- non-ANSI behavior of treating the function return type inferred
- from the current function definition as a declaration of the
- return type from any function of that name, the return type of NIL
- is attached to FOO in 120a above, and used to optimize code which
- calls FOO.
-
124:
As of version 0.pre7.14, SBCL's implementation of MACROLET makes
the entire lexical environment at the point of MACROLET available
* '``(FOO ,@',@S)
``(FOO SB-IMPL::BACKQ-COMMA-AT S)
+ c. (reported by Paul F. Dietz)
+ * '`(lambda ,x)
+ `(LAMBDA (SB-IMPL::BACKQ-COMMA X))
+
143:
(reported by Jesse Bouwman 2001-10-24 through the unfortunately
prominent SourceForge web/db bug tracking system, which is
The careful type of X is {2k} :-(. Is it really important to be
able to work with unions of many intervals?
-190: "PPC/Linux pipe? buffer? bug"
- In sbcl-0.7.6, the run-program.test.sh test script sometimes hangs
- on the PPC/Linux platform, waiting for a zombie env process. This
- is a classic symptom of buffer filling and deadlock, but it seems
- only sporadically reproducible.
-
191: "Miscellaneous PCL deficiencies"
(reported by Alexey Dejneka sbcl-devel 2002-08-04)
a. DEFCLASS does not inform the compiler about generated
classes). This means that at present erroneous attempts to use
WITH-SLOTS and the like on classes with metaclass STRUCTURE-CLASS
won't get the corresponding STYLE-WARNING.
- c. the examples in CLHS 7.6.5.1 (regarding generic function lambda
- lists and &KEY arguments) do not signal errors when they should.
+ c. (fixed in 0.8.4.23)
201: "Incautious type inference from compound types"
a. (reported by APD sbcl-devel 2002-09-17)
all of the arguments are circular is probably desireable).
213: "Sequence functions and type checking"
- a. MAKE-SEQUENCE, COERCE, MERGE and CONCATENATE cannot deal with
- various complicated, though recognizeable, CONS types [e.g.
- (CONS * (CONS * NULL))
- which according to ANSI should be recognized] (and, in SAFETY 3
- code, should return a list of LENGTH 2 or signal an error)
+ a. (fixed in 0.8.4.36)
b. MAP, when given a type argument that is SUBTYPEP LIST, does not
check that it will return a sequence of the given type. Fixing
it along the same lines as the others (cf. work done around
; The variable Y is defined but never used.
245: bugs in disassembler
- a. On X86 an immediate operand for IMUL is printed incorrectly.
b. On X86 operand size prefix is not recognized.
-248: "reporting errors in type specifier syntax"
- (TYPEP 1 '(SYMBOL NIL)) says something about "unknown type
- specifier".
-
251:
(defun foo (&key (a :x))
(declare (fixnum a))
b. The same for CSUBTYPEP.
-261:
- * (let () (list (the (values &optional fixnum) (eval '(values)))))
- debugger invoked on condition of type TYPE-ERROR:
- The value NIL is not of type FIXNUM.
-
262: "yet another bug in inline expansion of local functions"
Compiler fails on
Urgh... It's time to write IR1-copier.
-265:
- SB-EXT:RUN-PROGRAM is currently non-functional on Linux/PPC;
- attempting to use it leads to segmentation violations. This is
- probably because of a bogus implementation of
- os_restore_fp_control().
-
266:
David Lichteblau provided (sbcl-devel 2003-06-01) a patch to fix
behaviour of streams with element-type (SIGNED-BYTE 8). The patch
this problem.
288: fundamental cross-compilation issues (from old UGLINESS file)
- 288a: Using host floating point numbers to represent target
- floating point numbers, or host characters to represent
- target characters, is theoretically shaky. (The characters
- are OK as long as the characters are in the ANSI-guaranteed
- character set, though, so they aren't a real problem as
- long as the sources don't need anything but that.)
- 288b: The compiler still makes assumptions about cross-compilation-host
- implementation of ANSI CL:
- 288b1: Simple bit vectors are distinct from simple vectors (in
- DEFINE-STORAGE-BASE and elsewhere). (Actually, I'm not *sure*
- that things would really break if this weren't so, but I
- strongly suspect that they would.)
- 288b2: SINGLE-FLOAT is distinct from DOUBLE-FLOAT. (This is
- in a sense just one aspect of bug 288a.)
+ Using host floating point numbers to represent target floating point
+ numbers, or host characters to represent target characters, is
+ theoretically shaky. (The characters are OK as long as the characters
+ are in the ANSI-guaranteed character set, though, so they aren't a
+ real problem as long as the sources don't need anything but that;
+ the floats are a real problem.)
289: "type checking and source-transforms"
a.
the control word; however, this clobbers any change the user might
have made.
-295:
- From Paul Dietz:
-
- (ash -1000000000000 -10000000000000000000) ==> 0 ;; should be -1
-
296:
(reported by Adam Warner, sbcl-devel 2003-09-23)
argument. As a result, files with Lisp pathname pattern characters
(#\* or #\?, for instance) or quotation marks can cause the system
to perform arbitrary behaviour.
+
+297:
+ LOOP with non-constant arithmetic step clauses suffers from overzealous
+ type constraint: code of the form
+ (loop for d of-type double-float from 0d0 to 10d0 by x collect d)
+ compiles to a type restriction on X of (AND DOUBLE-FLOAT (REAL
+ (0))). However, an integral value of X should be legal, because
+ successive adds of integers to double-floats produces double-floats,
+ so none of the type restrictions in the code is violated.
+
+300: (reported by Peter Graves) Function PEEK-CHAR checks PEEK-TYPE
+ argument type only after having read a character. This is caused
+ with EXPLICIT-CHECK attribute in DEFKNOWN. The similar problem
+ exists with =, /=, <, >, <=, >=. They were fixed, but it is probably
+ less error prone to have EXPLICIT-CHECK be a local declaration,
+ being put into the definition, instead of an attribute being kept in
+ a separate file; maybe also put it into SB-EXT?
+
+301: ARRAY-SIMPLE-=-TYPE-METHOD breaks on corner cases which can arise
+ in NOTE-ASSUMED-TYPES
+ In sbcl-0.8.7.32, compiling the file
+ (defun foo (x y)
+ (declare (type integer x))
+ (declare (type (vector (or hash-table bit)) y))
+ (bletch 2 y))
+ (defun bar (x y)
+ (declare (type integer x))
+ (declare (type (simple-array base (2)) y))
+ (bletch 1 y))
+ gives the error
+ failed AVER: "(NOT (AND (NOT EQUALP) CERTAINP))"
+
+302: Undefined type messes up DATA-VECTOR-REF expansion.
+ Compiling this file
+ (defun dis (s ei x y)
+ (declare (type (simple-array function (2)) s) (type ei ei))
+ (funcall (aref s ei) x y))
+ on sbcl-0.8.7.36/X86/Linux causes a BUG to be signalled:
+ full call to SB-KERNEL:DATA-VECTOR-REF
+
+303: "nonlinear LVARs" (aka MISC.293)
+ (defun buu (x)
+ (multiple-value-call #'list
+ (block foo
+ (multiple-value-prog1
+ (eval '(values :a :b :c))
+ (catch 'bar
+ (if (> x 0)
+ (return-from foo
+ (eval `(if (> ,x 1)
+ 1
+ (throw 'bar (values 3 4)))))))))))
+
+ (BUU 1) returns garbage.
+
+ The problem is that both EVALs sequentially write to the same LVAR.
+
+305:
+ (Reported by Dave Roberts.)
+ Local INLINE/NOTINLINE declaration removes local FTYPE declaration:
+
+ (defun quux (x)
+ (declare (ftype (function () (integer 0 10)) fee)
+ (inline fee))
+ (1+ (fee)))
+
+ uses generic arithmetic with INLINE and fixnum without.
+
+306: "Imprecise unions of array types"
+ a.(defun foo (x)
+ (declare (optimize speed)
+ (type (or (array cons) (array vector)) x))
+ (elt (aref x 0) 0))
+ (foo #((0))) => TYPE-ERROR
+
+ relatedly,
+
+ b.(subtypep
+ 'array
+ `(or
+ ,@(loop for x across sb-vm:*specialized-array-element-type-properties*
+ collect `(array ,(sb-vm:saetp-specifier x)))))
+ => NIL, T (when it should be T, T)
+
+308: "Characters without names"
+ (reported by Bruno Haible sbcl-devel "character names are missing"
+ 2004-04-19)
+ (graphic-char-p (code-char 255))
+ => NIL
+ (char-name (code-char 255))
+ => NIL
+
+ SBCL is unsure of what to do about characters with codes in the
+ range 128-255. Currently they are treated as non-graphic, but don't
+ have names, which is not compliant with the standard. Various fixes
+ are possible, such as
+ * giving them names such as NON-ASCII-128;
+ * reducing CHAR-CODE-LIMIT to 127 (almost certainly unpopular);
+ * making the characters graphic (makes a certain amount of sense);
+ * biting the bullet and implementing Unicode (probably quite hard).
+
+309: "Dubious values for implementation limits"
+ (reported by Bruno Haible sbcl-devel "Incorrect value of
+ multiple-values-limit" 2004-04-19)
+ (values-list (make-list 1000000)), on x86/linux, signals a stack
+ exhaustion condition, despite MULTIPLE-VALUES-LIMIT being
+ significantly larger than 1000000. There are probably similar
+ dubious values for CALL-ARGUMENTS-LIMIT (see cmucl-help/cmucl-imp
+ around the same time regarding a call to LIST on sparc with 1000
+ arguments) and other implementation limit constants.
+
+310: "Floating point printing inaccuracy"
+ (reported by Bruno Haible sbcl-devel "print-read consistency for
+ floating point numbers" 2004-04-19)
+ (let ((x (/ -9.349640046247849d-21 -9.381494249123696d-11)))
+ (let ((y (read-from-string (write-to-string x :readably t))))
+ (eql x y)))
+ should return T but, as of sbcl-0.8.9.51, returns NIL.
+
+ That this is a bug in the printer is demonstrated by
+ (setq x1 (float -5496527/100000000000000000))
+ (setq x2 (float -54965272/1000000000000000000))
+ (integer-decode-float x1) => 15842660 -58 -1
+ (integer-decode-float x2) => 15842661 -58 -1
+ (prin1-to-string x1) => "-5.496527e-11"
+ (prin1-to-string x2) => "-5.496527e-11" ; should be different!
+
+ Note also the following comment from src/code/print.lisp:
+ ;;; NOTE: When a number is to be printed in exponential format, it is
+ ;;; scaled in floating point. Since precision may be lost in this
+ ;;; process, the guaranteed accuracy properties of FLONUM-TO-STRING
+ ;;; are lost. The difficulty is that FLONUM-TO-STRING performs
+ ;;; extensive computations with integers of similar magnitude to that
+ ;;; of the number being printed. For large exponents, the bignums
+ ;;; really get out of hand. If bignum arithmetic becomes reasonably
+ ;;; fast and the exponent range is not too large, then it might become
+ ;;; attractive to handle exponential notation with the same accuracy
+ ;;; as non-exponential notation, using the method described in the
+ ;;; Steele and White paper.
+
+ See also CSR sbcl-devel with an implementation of Berger and
+ Dybvig's algorithm for printing and a fix for reading.
+
+311: "Tokeniser not thread-safe"
+ (see also Robert Marlow sbcl-help "Multi threaded read chucking a
+ spak" 2004-04-19)
+ The tokenizer's use of *read-buffer* and *read-buffer-length* causes
+ spurious errors should two threads attempt to tokenise at the same
+ time.
+
+312:
+ (reported by Jon Dyte)
+ SBCL issues a warning "Duplicate definition of FOO" compiling
+
+ (declaim (inline foo))
+ (defun foo (x)
+ (1+ x))
+ (defun bar (y)
+ (list (foo y) (if (> y 1) (funcall (if (> y 0) #'foo #'identity) y))))
+
+ (probably related to the bug 280.)
+
+313: "source-transforms are Lisp-1"
+ (fixed in 0.8.10.2)
projects / sbcl.git / blobdiff