(get-output-stream-string out-stream))
;; (Before the fix, the LET* expression just signalled an error.)
"a"))
+;;; ... and yet, a little over 6 years on, echo-streams were still
+;;; broken when a read-char followed the unread/peek sequence. Do
+;;; people not actually use echo-streams? RMK, 2009-04-02.
+(assert (string=
+ (let* ((in-stream (make-string-input-stream "abc"))
+ (out-stream (make-string-output-stream))
+ (echo-stream (make-echo-stream in-stream out-stream)))
+ (unread-char (read-char echo-stream) echo-stream)
+ (peek-char nil echo-stream)
+ (read-char echo-stream)
+ (get-output-stream-string out-stream))
+ ;; before ca. 1.0.27.18, the LET* returned "aa"
+ "a"))
;;; Reported by Fredrik Sandstrom to sbcl-devel 2005-05-17 ("Bug in
;;; peek-char"):
(frob 'base-char)
(frob 'nil))
-(with-open-file (s "/dev/null" :element-type '(signed-byte 48))
+(with-open-file (s #-win32 "/dev/null" #+win32 "nul" :element-type '(signed-byte 48))
(assert (eq :eof (read-byte s nil :eof))))
(let* ((is (make-string-input-stream "foo"))
(assert (string= (get-output-stream-string os) "foo")))
(with-standard-io-syntax
- (open "/dev/null"))
+ (open #-win32 "/dev/null" #+win32 "nul" ))
;;; PEEK-CHAR T uses whitespace[2]
(let ((*readtable* (copy-readtable)))
;;; improperly.
;;;
;;; This test assumes that buffering is still done until a buffer of
-;;; SB-IMPL::BYTES-PER-BUFFER bytes is filled up, that the buffer may
+;;; SB-IMPL::+BYTES-PER-BUFFER+ bytes is filled up, that the buffer may
;;; immediately be completely filled for normal files, and that the
;;; buffer-fill routine is responsible for figuring out when we've
;;; reached EOF.
-(with-test (:name (stream listen-vs-select))
+(with-test (:name (stream listen-vs-select) :fails-on :win32)
(let ((listen-testfile-name "stream.impure.lisp.testqfile")
;; If non-NIL, size (in bytes) of the file that will exercise
;; the LISTEN problem.
(bytes-per-buffer-sometime
- (and (boundp 'sb-impl::bytes-per-buffer)
- (symbol-value 'sb-impl::bytes-per-buffer))))
+ (and (boundp 'sb-impl::+bytes-per-buffer+)
+ (symbol-value 'sb-impl::+bytes-per-buffer+))))
(when bytes-per-buffer-sometime
(unwind-protect
(progn
(read-byte stream))
(assert (not (listen stream)))))
(ignore-errors (delete-file listen-testfile-name))))))
+
+(with-test (:name :bug-395)
+ (let ((v (make-array 5 :fill-pointer 0 :element-type 'standard-char)))
+ (format v "foo")
+ (assert (equal (coerce "foo" 'base-string) v))))
+
+;;; Circa 1.0.27.18, echo-streams were changed somewhat, so that
+;;; unread-char on an echo-stream propagated the character down to the
+;;; echo-stream's input stream. (All other implementations but CMUCL
+;;; seemed to do this). The most useful argument for this behavior
+;;; involves cases where an input operation on an echo-stream finishes
+;;; up by unreading a delimiter, and the user wants to proceed to use the
+;;; underlying stream, e.g.,
+(assert (equal
+ (with-input-from-string (in "foo\"bar\"")
+ (with-open-stream (out (make-broadcast-stream))
+ (with-open-stream (echo (make-echo-stream in out))
+ (read echo)))
+ (read in))
+ ;; Before ca 1.0.27.18, the implicit UNREAD-CHAR at the end of
+ ;; the first READ wouldn't get back to IN, so the second READ
+ ;; returned BAR, not "BAR" (and then subsequent reads would
+ ;; lose).
+ "bar"))