------- Comment #6 from tsyvarev at ispras dot ru 2008-10-31 10:48 -------
(In reply to comment #2)
> Maybe now I see, what's behind your report: you believe that, when val is set,
> eofbit should be set only when seeking another character to match. But that
> would essentially boil down to *never* set it, in that case, because val is
> set
> only when a target sequence is uniquely matched, thus we don't look beyond the
> last matched character.
I suppose there is a situations when eofbit is set:
Assume, sequence is "fals". Because "fals" is prefix of "false", do_get()
should try to obtained character after 's', but it found, that (in==end). So it
should set err to (failbit | eofbit).
Here is an example of a situation when this difference between standard and
current implementation may be significant.
Consider the stream, in which operation (in == end) will block process until a
character is available. So, comparision (in == end) always returns false, until
stream is forced to close.
For example, assume the stream is connected to terminal. So if the stream is
depleted but the program performs the comparison (in == end), current process
will be blocked until the user inputs another character.
For the prompt "Are you sure to perform this operation?" it is sufficient for
the user to input {'y', 'e', 's'} and program will interpret this as
affirmative answer.
But for current implementation user should input {'y', 'e', 's', <enter>},
because after reading "yes" do_get() performs the comparison (in == end) to
verify whether eofbit should be set in err. But this call will block program
until the user inputs another character, which does not affect the
interpretation of the user's answer, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
