Opened 6 years ago

#1122 new defect

bug in peek-char for CRLF-type line-endings

Reported by: mhd Owned by:
Priority: normal Milestone:
Component: ANSI CL Compliance Version: trunk
Keywords: newline, stream, line endings Cc:


On CCL for Windows currently (11/15/13), version: Clozure Common Lisp Version 1.9-r15764 (WindowsX8632), when reading from a character stream with line-ending inferred (and presumably with line-ending CRLF, but I haven't checked) READ-CHAR automatically converts CRLF sequences to the character #\newline. However, PEEK-CHAR does not do so.

They should be consistent. The READ-CHAR behavior should be emulated by PEEK-CHAR.

The following

(defun test-peek (&optional (pathname "test-peek.txt")
                  &aux reading-1 reading-2)
  (with-open-file (out pathname
                       :if-exists :supersede
                       :if-does-not-exist :create
                       :direction :output
                       :element-type '(UNSIGNED-BYTE 8))
    (loop for c in '(#\p #\e #\e #\k)
          do (write-byte (char-code c) out)
             (write-byte (char-code #\return) out)
             (write-byte (char-code #\linefeed) out)))
  (setq reading-1
        (with-open-file (in pathname)
          (loop for c = (read-char in nil nil)
                while c collect c)))
  (setq reading-2
        (with-open-file (in pathname)
          (loop for c = (prog1 (peek-char nil in nil nil)
                          (read-char in nil nil))
                while c collect c)))
   (equal reading-1 reading-2)
   reading-1 reading-2))

should return T as first value on Windows. In SBCL and LispWorks? it returns T, but in CCL it returns nil.

For second and third values:

  CCL: (#\p LF #\e LF #\e LF #\k LF) / (#\p CR #\e CR #\e CR #\k CR)
  SBCL: (#\p CR LF #\e CR LF #\e CR LF #\k CR LF) / same
  Lispworks: (#\p LF #\e LF #\e LF #\k LF) / same

Goal should be to return the same thing as Lispworks (where LF = #\Newline).

Change History (0)

Note: See TracTickets for help on using tickets.