#171 unread-char bug with file in Mac encoding
Hi,
UNREAD-CHAR #\newline seems to break consistency when
reading from a file with Macintosh end of line
convention (CR only).
(defun read-until-newline (s)
(let ((ch (read-char s)))
(if (eql ch #\newline) (unread-char ch s)
(read-until-newline s))))
(defun write-test-file ()
(with-open-file (f "/tmp/bininput" :element-type
'(unsigned-byte 8) :direction\
:output :if-exists :supersede)
(write-sequence '#(97 98 13 65 66 10) f)))
(setq f (open "/tmp/bininput" :element-type
'character))
;; :external-format :mac doesn't help either
1. Break [23]> (read-until-newline f)
NIL
1. Break [23]> (read-char f)
#\Newline
1. Break [23]> (read-until-newline f)
NIL
1. Break [23]> (setf (stream-element-type f)
'(unsigned-byte 8))
(UNSIGNED-BYTE 8)
1. Break [23]> (setf (stream-element-type f)
'character)
CHARACTER
1. Break [23]> (peek-char nil f)
NIL ; ouch!
1. Break [23]> (read-char f)
NIL ; ouch!
1. Break [23]> (read-char f)
#\A ; back in sync again
(close f)
Alternatively (symptom 2)
(ext:letf (((stream-element-type f) '(unsigned-byte
8)))
(format t "~d - ~d~%" (read-byte f) (read-byte
f)) ;-> 122 - 65
) ; 122 (#\z) looks like random (but repeatable) junk
(read-char f) -> #\B ; normal again
Using CVS CLISP (or nearly so), --without-unicode
Symptom 1 disappears when using :buffered nil
Symptom 2 (byte 122) remains. So it may be 2 distinct
faults.
Not that this is of interest to CLISP, but the simple
streams proposal mandates to unread back multi-byte
characters (to the octets they once were). But that's a
different story.
Regards,
Jörg Höhle
Logged In: YES
user_id=5735
I am not sure how to handle this, so I pass it on to Bruno