Loading BUGS +8 −46 Original line number Diff line number Diff line Loading @@ -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?) Loading Loading @@ -377,14 +368,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 Loading Loading @@ -464,6 +447,8 @@ WORKAROUND: * '``(FOO ,@',@S) ``(FOO SB-IMPL::BACKQ-COMMA-AT S) b. (fixed in 0.8.4.7) 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is Loading Loading @@ -890,10 +875,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)) Loading Loading @@ -978,12 +959,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 Loading Loading @@ -1172,20 +1147,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. Loading Loading @@ -1216,11 +1183,6 @@ WORKAROUND: 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) Loading NEWS +2 −0 Original line number Diff line number Diff line Loading @@ -2132,6 +2132,8 @@ changes in sbcl-0.8.5 relative to sbcl-0.8.4: * fixed bug 213a: even fairly unreasonable CONS type specifiers are now understood by sequence creation functions such as MAKE-SEQUENCE and COERCE. * fixed bug 46k: READ-BYTE now signals an error when asked to read from a STRING-INPUT-STREAM. * compiler enhancement: SIGNUM is now better able to derive the type of its result. * type declarations inside WITH-SLOTS are checked. (reported by Loading src/code/stream.lisp +1 −1 Original line number Diff line number Diff line Loading @@ -1085,7 +1085,7 @@ (defstruct (string-input-stream (:include string-stream (in #'string-inch) (bin #'string-binch) (bin #'ill-bin) (n-bin #'string-stream-read-n-bytes) (misc #'string-in-misc) (string (missing-arg) :type simple-string)) Loading tests/stream.impure.lisp +5 −0 Original line number Diff line number Diff line Loading @@ -76,5 +76,10 @@ (close stream) (delete-file p)) (assert (raises-error? (read-byte (make-string-input-stream "abc")) type-error)) (assert (raises-error? (with-open-file (s "/dev/random") (read-byte s)) type-error)) ;;; success (quit :unix-status 104) version.lisp-expr +1 −1 Original line number Diff line number Diff line Loading @@ -17,4 +17,4 @@ ;;; checkins which aren't released. (And occasionally for internal ;;; versions, especially for internal versions off the main CVS ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".) "0.8.4.36" "0.8.4.37" Loading
BUGS +8 −46 Original line number Diff line number Diff line Loading @@ -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?) Loading Loading @@ -377,14 +368,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 Loading Loading @@ -464,6 +447,8 @@ WORKAROUND: * '``(FOO ,@',@S) ``(FOO SB-IMPL::BACKQ-COMMA-AT S) b. (fixed in 0.8.4.7) 143: (reported by Jesse Bouwman 2001-10-24 through the unfortunately prominent SourceForge web/db bug tracking system, which is Loading Loading @@ -890,10 +875,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)) Loading Loading @@ -978,12 +959,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 Loading Loading @@ -1172,20 +1147,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. Loading Loading @@ -1216,11 +1183,6 @@ WORKAROUND: 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) Loading
NEWS +2 −0 Original line number Diff line number Diff line Loading @@ -2132,6 +2132,8 @@ changes in sbcl-0.8.5 relative to sbcl-0.8.4: * fixed bug 213a: even fairly unreasonable CONS type specifiers are now understood by sequence creation functions such as MAKE-SEQUENCE and COERCE. * fixed bug 46k: READ-BYTE now signals an error when asked to read from a STRING-INPUT-STREAM. * compiler enhancement: SIGNUM is now better able to derive the type of its result. * type declarations inside WITH-SLOTS are checked. (reported by Loading
src/code/stream.lisp +1 −1 Original line number Diff line number Diff line Loading @@ -1085,7 +1085,7 @@ (defstruct (string-input-stream (:include string-stream (in #'string-inch) (bin #'string-binch) (bin #'ill-bin) (n-bin #'string-stream-read-n-bytes) (misc #'string-in-misc) (string (missing-arg) :type simple-string)) Loading
tests/stream.impure.lisp +5 −0 Original line number Diff line number Diff line Loading @@ -76,5 +76,10 @@ (close stream) (delete-file p)) (assert (raises-error? (read-byte (make-string-input-stream "abc")) type-error)) (assert (raises-error? (with-open-file (s "/dev/random") (read-byte s)) type-error)) ;;; success (quit :unix-status 104)
version.lisp-expr +1 −1 Original line number Diff line number Diff line Loading @@ -17,4 +17,4 @@ ;;; checkins which aren't released. (And occasionally for internal ;;; versions, especially for internal versions off the main CVS ;;; branch, it gets hairier, e.g. "0.pre7.14.flaky4.13".) "0.8.4.36" "0.8.4.37"