+
+(with-standard-io-syntax
+ (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"))