bug-guile
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#12216: peek-char incorrectly *CONSUMES* eof


From: Andy Wingo
Subject: bug#12216: peek-char incorrectly *CONSUMES* eof
Date: Wed, 13 Mar 2013 19:22:41 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

On Wed 13 Mar 2013 19:10, Mark H Weaver <address@hidden> writes:

> Andy Wingo <address@hidden> writes:
>
>> On Wed 13 Mar 2013 14:09, "David A. Wheeler" <address@hidden> 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/





reply via email to

[Prev in Thread] Current Thread [Next in Thread]