X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=BUGS;h=365e53762053f536218cbab84e0e19aa81b853d5;hb=286cb407fcf618572b874ace57c119fe284d14c5;hp=cb7b79beaf0b3637df3821d854ac2c47c1915b0b;hpb=6053e7f804b430144bb09e2d107ad4ab3fb97db4;p=sbcl.git diff --git a/BUGS b/BUGS index cb7b79b..365e537 100644 --- a/BUGS +++ b/BUGS @@ -184,15 +184,6 @@ WORKAROUND: (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?) @@ -273,6 +264,11 @@ WORKAROUND: 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 @@ -333,6 +329,15 @@ WORKAROUND: 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. @@ -377,14 +382,6 @@ WORKAROUND: 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 @@ -464,11 +461,9 @@ WORKAROUND: * '``(FOO ,@',@S) ``(FOO SB-IMPL::BACKQ-COMMA-AT S) - b. - * (write '`(, .ala.) :readably t :pretty t) - `(,.ALA.) - - (note the space between the comma and the point) + 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 @@ -621,12 +616,6 @@ WORKAROUND: 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 @@ -646,8 +635,7 @@ WORKAROUND: 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) @@ -734,11 +722,7 @@ WORKAROUND: 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 @@ -753,20 +737,6 @@ WORKAROUND: (INTEGERP (CAR (MAKE-SEQUENCE '(CONS INTEGER *) 2))) can erroneously return T. -214: - SBCL 0.6.12.43 fails to compile - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (flet ((foo (&key (x :vx x-p)) (list x x-p))) - (foo 1 2))) - - or a more simple example: - - (locally - (declare (optimize (inhibit-warnings 0) (compilation-speed 2))) - (lambda (x) (declare (fixnum x)) (if (< x 0) 0 (1- x)))) - 215: ":TEST-NOT handling by functions" a. FIND and POSITION currently signal errors when given non-NIL for both their :TEST and (deprecated) :TEST-NOT arguments, but by @@ -915,10 +885,6 @@ WORKAROUND: 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)) @@ -981,11 +947,6 @@ WORKAROUND: 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 @@ -1008,12 +969,6 @@ WORKAROUND: 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 @@ -1170,16 +1125,6 @@ WORKAROUND: The issue seems to be that construction of a discriminating function calls COMPUTE-EFFECTIVE-METHOD with methods that are not all applicable. -282: "type checking in full calls" - In current (0.8.3.6) implementation a CAST in a full call argument - is not checked; but the continuation between the CAST and the - combination has the "checked" type and CAST performs unsafe - coercion; this may lead to errors: if FOO is declared to take a - FIXNUM, this code will produce garbage on a machine with 30-bit - fixnums: - - (foo (aref (the (array (unsigned-byte 32)) x))) - 283: Thread safety: libc functions There are places that we call unsafe-for-threading libc functions that we should find alternatives for, or put locks around. Known or @@ -1212,20 +1157,12 @@ WORKAROUND: 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. @@ -1256,36 +1193,61 @@ WORKAROUND: the control word; however, this clobbers any change the user might have made. -291: "bugs in deletion of embedded functions" - - Python fails to compile (simplified version of the problem reported - by Nikodemus Siivola) - - (defstruct (line) - (%chars "")) - - (defun update-window-imag (line) - (tagbody - TOP - (if (null line) - (go DONE) - (go TOP)) - DONE - (unless (eq current the-sentinel) - (let* ((cc (car current)) - (old-line (dis-line-line cc))) - (if (eq old-line line) - (do ((chars (line-%chars line) nil)) ; - (()) - (let* () - (multiple-value-call - #'(lambda (&optional g2740 g2741 &rest g2742) - (declare (ignore g2742)) - (catch 'foo ; - (values (setq string g2740) (setq underhang g2741)))) - (foo))) - (setf (dis-line-old-chars cc) chars))))))) - - Compiler deletes unreachable BIND node of , but its body, - including reference to the variable CHARS, remains reachable through - NLX from . +296: + (reported by Adam Warner, sbcl-devel 2003-09-23) + + The --load toplevel argument does not perform any sanitization of its + 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. + +298: (aka PFD MISC.183) + Compiler fails on + + (defun foo () + (multiple-value-call #'bar + (ext) + (catch 'tag (return-from foo (int))))) + + This program violates "unknown values LVAR stack discipline": if INT + returns, values returned by (EXT) must be removed from under that of + (INT). + +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