Subject: [clisp-list] Possible bug: PEEK-CHAR advances file pointer

From: Bob Bechtel <[email-masked]>
Date: Fri Nov 22 13:18:05 2002

I'm not sure this is a bug -- it may be a question of CL Spec 
interpretation.  Here's the bug data:

1. Platform: Windows 2000, SP2. Hardware is P4, 512M.
2-4. I'm using a binary distribution, clisp-2.30-win32.zip. I may be 
able to rebuild from sources, but would prefer to wait until this is 
confirmed as an error, rather than just a permissible CL spec 
interpretation.
5. lisp --version
GNU CLISP 2.30 (released 2002-09-15) (built 2002-09-15 11:22:41)
Features: (CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS 
GENERIC-STREAMS
 LOGICAL-PATHNAMES SCREEN FFI UNICODE BASE-CHAR=CHARACTER SYSCALLS 
DIR-KEY PC386
 WIN32)
6. Example...

I did (setf bbna (merge-pathnames "I.NEX")) to get a pathname to an 
existing file.  Then

[10]> (with-open-file (foo bbna)
(format t "~%Current file position = ~A~%"
(file-position foo))
(format t "PEEK-CHAR gets ~C~%" (peek-char nil foo))
(format t "File position is now ~A~%" (file-position foo))
(format t "Second PEEK-CHAR gets ~C~%" (peek-char nil foo))
(format t " while making file position ~A~%"
(file-position foo)))

Current file position = 0
PEEK-CHAR gets i
File position is now 1
Second PEEK-CHAR gets i
 while making file position 1
NIL

I was expecting that the file position would remain 0 through both 
PEEK-CHAR calls.  The other CL
implementations I've tried (Allegro, Corman, and Lispworks) all keep 
file position at 0, but as I look
through the Hyperspec, it says that (PEEK-CHAR NIL ...) must keep the 
character in the buffer for subsequent operations, but doesn't 
explicitly require the file pointer to remain unchanged.

So, I don't know if this is really a bug, or just a permissible (though 
surprising to me) interpretation of
the spec.

Suggestions? Thanks!

bob bechtel

---

From: Sam Steingold <[email-masked]>
Date: Tue Dec 3 09:31:07 2002

please try the appended patch

> * In message <[email-masked]>
> * On the subject of "[clisp-list] Possible bug: PEEK-CHAR advances file pointer"
> * Sent on Fri, 22 Nov 2002 15:20:27 -0600
> * Honorable Bob Bechtel <[email-masked]> writes:
>
> PEEK-CHAR calls.  The other CL implementations I've tried (Allegro,
> Corman, and Lispworks) all keep file position at 0, but as I look
> So, I don't know if this is really a bug, or just a permissible
> (though surprising to me) interpretation of the spec.
> 
> Suggestions? Thanks!

-- 
Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux
<http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/>
<http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html>
Abandon all hope, all ye who press Enter.

Index: stream.d
===================================================================
RCS file: /cvsroot/clisp/clisp/src/stream.d,v
retrieving revision 1.317
diff -u -w -b -u -b -w -i -B -r1.317 stream.d
--- stream.d	2 Dec 2002 14:24:19 -0000	1.317
+++ stream.d	3 Dec 2002 17:29:08 -0000
@@ -17260,7 +17260,10 @@
   } else {
     if (!boundp(position)) {
       # position not specified -> Position as value:
-      VALUES1(UL_to_I(BufferedStream_position(stream)));
+      VALUES1(UL_to_I(BufferedStream_position(stream) -
+                      /* if a character has been unread, decrement position */
+                      (TheStream(stream)->strmflags & strmflags_unread_B
+                       ? 1 : 0)));
     } else {
       if (eq(position,S(Kstart))) {
         # :START -> set position to start: