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

Previous Next

Full log

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

From: Andy Wingo <wingo <at> pobox.com>
To: Mark H Weaver <mhw <at> netris.org>
Cc: almkglor <almkglor <at> gmail.com>, dwheeler <at> dwheeler.com,
	12216 <12216 <at> debbugs.gnu.org>
Subject: Re: bug#12216: peek-char incorrectly *CONSUMES* eof
Date: Wed, 13 Mar 2013 19:22:41 +0100

On Wed 13 Mar 2013 19:10, Mark H Weaver <mhw <at> netris.org> writes:

> Andy Wingo <wingo <at> pobox.com> writes:
>
>> On Wed 13 Mar 2013 14:09, "David A. Wheeler" <dwheeler <at> dwheeler.com> writes:
>>
>>> Andy Wingo:
>>>
>>>> So, we are repeating ourselves here :)  I agree with you but I can't see
>>>> a good way of implementing this.
>>>
>>> Would the per-port reader options be reasonable place to store the info
>>> about EOF?
>>
>> For your own purposes that would be fine.  But it cannot affect
>> read-char / peek-char / etc for everyone, because it would have bad
>> global effects on performance and correctness.  That's why I'm pushing
>> back on fixing this in Guile itself.
>
> I don't know, it might not be that bad, now that we've agreed on a way
> to extend the port structure in 2.0.  Maybe we could just have a "last
> peek-char returned EOF" flag that would be consulted by the other read
> primitives.
>
> I agree that we should not allow EOF to be unread.
>
> What do you think?

I really doubt our ability to get it right.  Consider that we have code
that accesses the buffer directly, binary and textual ports, etc
etc... I don't think we're going to get this right.  Fixing this would
also have complexity and performance costs as well.

Maybe if it is somehow confined to scm_peek_char and scm_fill_input it
could be doable.

Andy
-- 
http://wingolog.org/

Previous Next

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