This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: Silently passing wrong input for good one
Martin Sebor wrote:
> I suspect it wouldn't be easy in the default case (istreambuf_iterator)
> although the charT* specializations might be able to be more robust.
> If the default implementation can't backtrack it should probably set
> failbit since it consumed a sequence that would (or should) cause scanf
> to report an input failure (I'm assuming you agree that "-3e-" is not
> a valid subject sequence).
But then we have a defect in the standard, because according to the
standard Stage2 goes ahead according to the grammar, on input_iterators,
and only at the end, Stage 3 kicks in with the role of scanf...
> The point I'm trying to make is that even if glibc swallows the extra
> characters (and even if the C standard required it to do so, which I
> don't believe is the case(*)), I wouldn't consider such behavior (or
> requirement) desirable or reasonable, and thus wouldn't expect a C++
> implementation to try to provide compatibility with it.
... basically, the standard, with such separation in Stages (first,
grammar on input_iterators, then scanf), demands an overall behavior
which is identical to that of glibc.
I don't think there is much point in diverging from glibc without such a
clarification in the C++ standard.
Paolo.