------- Comment #9 from tsyvarev at ispras dot ru 2008-11-01 12:21 -------
Patch seems doesn't resolve problem entirely.
The thing is that, besides of constraints on setting eofbit flag, the standard
claims, that comparision (in == end) should be perfomed only when it is needed
for identify a match(22.2.2.1.2, p15):
"Successive characters in the range [in,end) (see 23.1.1) are obtained and
matched against corresponding positions in the target sequences ONLY as
necessary to identify a unique match. The input iterator in is compared
to end ONLY when necessary to obtain a character."
If also take into account constraints on setting eofbit flag:
"if, when seeking another character to match, it is found that (in == end)" and
"if the reason for the failure was that (in == end).",
one may conclude, that
eofbit flag should be set IF and ONLY IF comparision (in == end) was performed
and it returned true.
Declaration
bool __testeof = __beg == __end;
in the patched code means, that implementation always compares (in == end) at
start, even when input and target sequences are empty (""). In that case, err
will be set to failbit, which conforms to the example in the standard:
"For empty targets (""), any input sequence yields err == str.failbit"
But input sequence should not be read at all in this case, so comparision (in
== end) should not be performed!
There are also other cases, when implementation performs unnecessary
comparision (in == end).
--
tsyvarev at ispras dot ru changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37958
