GNU bug report logs -
#12216
peek-char incorrectly *CONSUMES* eof
Previous Next
Reported by: dwheeler <at> dwheeler.com
Date: Fri, 17 Aug 2012 02:03:01 UTC
Severity: normal
Done: Mark H Weaver <mhw <at> netris.org>
Bug is archived. No further changes may be made.
Full log
Message #57 received at 12216 <at> debbugs.gnu.org (full text, mbox):
Andy Wingo <wingo <at> 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
This bug report was last modified 12 years and 108 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.