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

[Mark H Weaver <mhw@netris.org>]

Andy Wingo <wingo@pobox.com> writes:
> Maybe if it is somehow confined to scm_peek_char and scm_fill_input it
> could be doable.

I think I now see a reasonable way to fix this.

First of all, all interfaces that do something like 'peek' would, when
returning an EOF, set a 'pending_eof' flag in the port structure.  Then
'scm_fill_input' would start by checking this flag; if it is set, then
it would clear the flag and return EOF.

We would also need to clear the 'pending_eof' flag in a few other
places, most notably in 'scm_end_input'.  In theory, that might be
enough, but to be on the safe side we should also clear the flag in any
procedure that writes or seeks.

Note that there is one inlined 'peek' function: 'scm_peek_byte_or_eof'
defined in inline.h.  We can change it to set the 'pending_eof' flag,
but we must consider that some code will be compiled against the old
version.  This is not a serious problem.  It just means that if someone
calls the old 'scm_peek_byte_or_eof' and gets EOF, the EOF will be
swallowed and not properly repeated by the next 'read'.  Oh well.

I plan to cook up a patch along these lines soon, as part of my ports
work for 2.0.8.

   Thoughts?
     Mark