#171 unread-char bug with file in Mac encoding

lisp error
open
Bruno Haible
clisp (525)
5
2004-04-30
2003-05-20
Jörg Höhle
No

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

Discussion

  • Sam Steingold
    Sam Steingold
    2004-04-30

    • assigned_to: sds --> haible
     
  • Sam Steingold
    Sam Steingold
    2004-04-30

    Logged In: YES
    user_id=5735

    I am not sure how to handle this, so I pass it on to Bruno