GNU bug report logs - #12216
peek-char incorrectly *CONSUMES* eof

Previous Next

Full log

Message #20 received at 12216 <at> debbugs.gnu.org (full text, mbox):

From: "David A. Wheeler" <dwheeler <at> dwheeler.com>
To: "mandyke" <mandyke <at> gmail.com>
Cc: wingo <wingo <at> pobox.com>, almkglor <almkglor <at> gmail.com>,
	12216 <12216 <at> debbugs.gnu.org>
Subject: Re: bug#12216: peek-char incorrectly *CONSUMES* eof
Date: Sat, 09 Mar 2013 12:11:12 -0500 (EST)

Daniel Hartwig:
> Indeed.  There is a distinction between the end-of-file _object_
> (Scheme) and end-of-transmission _character_ (ASCII ^D).  The two are
> not equivalent, ...

Sure.

> and when read-char and peek-char return the former
> value it is only to signal a _current_ lack of characters and should
> not be considered part of the character stream read from the port.

If I understand you correctly, that sounds more like "char-ready?".

In any case, I believe guile fails to meet the semantics
of R5RS, and I believe other versions of the Scheme spec,
in this area.  R5RS says:

> (peek-char) procedure
> (peek-char port) procedure
> Returns the next character available from the input port,
> without updating the port to point to the following character.
> If no more characters are available, an end of le
> object is returned. Port may be omitted, in which case it
> defaults to the value returned by current-input-port.
> Note: The value returned by a call to peek-char is the same as
> the value that would have been returned by a call to read-char
> with the same port. The only difference is that the very next call
> to read-char or peek-char on that port will return the value
> returned by the preceding call to peek-char. In particular, a
> call to peek-char on an interactive port will hang waiting for
> input whenever a call to read-char would have hung.

Note that the spec says that the very next call
"to read-char or peek-char on that port will return the value
returned by the preceding call to peek-char."  It does not say
the same *CHARACTER*, it says the same *VALUE*, and the
eof object is a possible value from peek-char and read-char.

I'd be okay if, after a read-char of EOF, it could return something else
as some sort of extension.  But (peek-char) (peek-char) (peek-char)
should return the same values 3 times, no matter what... even
if it's EOF.

--- David A. Wheeler

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.