X-Git-Url: http://repo.macrolet.net/gitweb/?a=blobdiff_plain;f=tests%2Fstream.pure.lisp;h=50b2126be018014fc4bedcbf4df502ea5085ddff;hb=260de2062fca170efdac3e42491d7d866c2d2e56;hp=9e9d914b383c81f39ee80d8daa22caae458b95b6;hpb=c364434c07423e4b033f286397667b3fe0310e97;p=sbcl.git

diff --git a/tests/stream.pure.lisp b/tests/stream.pure.lisp
index 9e9d914..50b2126 100644
--- a/tests/stream.pure.lisp
+++ b/tests/stream.pure.lisp
@@ -73,6 +73,19 @@
            (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"):
@@ -261,7 +274,7 @@
   (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"))
@@ -292,10 +305,67 @@
   (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)))
   (assert (char= (peek-char t (make-string-input-stream " a")) #\a))
   (set-syntax-from-char #\Space #\a)
   (assert (char= (peek-char t (make-string-input-stream " a")) #\Space)))
+
+;;; It is actually easier to run into the problem exercised by this
+;;; test with sockets, due to their delays between availabilities of
+;;; data.  However edgy the case may be for normal files, however,
+;;; there is still a case to be found in which CL:LISTEN answers
+;;; 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
+;;; 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) :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+))))
+    (when bytes-per-buffer-sometime
+      (unwind-protect
+           (progn
+             (with-open-file (stream listen-testfile-name
+                                     :direction :output :if-exists :error
+                                     :element-type '(unsigned-byte 8))
+               (dotimes (n bytes-per-buffer-sometime)
+                 (write-byte 113 stream)))
+             (with-open-file (stream listen-testfile-name
+                                     :direction :input :element-type '(unsigned-byte 8))
+               (dotimes (n bytes-per-buffer-sometime)
+                 (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"))