[RFC] err |= ios_base::failbit or err = ios_base::failbit?!?

Nathan Myers ncm-nospam@cantrip.org
Mon Jan 5 22:05:00 GMT 2004


On Mon, Jan 05, 2004 at 02:02:18PM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> >Martin wrote:
> >>There is no text specifying what time_get does with the iostate
> >>argument, so it presumably defaults to 22.2, p2, creating an
> >>inconsistency between how the facets report errors to callers.
> >
> >A caller who passes a local variable initialized to ios_base::goodbit 
> >will not notice any inconsistency.  However, both are specified to
> >ignore the incoming state of the argument, so it's not strictly 
> >inconsistent.  It's just that the num_get<>::do_get members are a 
> >bit overactive -- or overspecified.
> 
> The problem is that the caller may have set the state to some
> value other than goodbit and expect to see that bit still set
> after a failed extraction. 

Such expectation would just be wrong, because it says that they 
assign failbit.  However, if they were to call with (e.g.) eofbit
set (perhaps by a previous call) and expect it still to be set even
after a successful extraction, then time_get<>::get would return
with eofbit, and num_get<>::get would return with goodbit.  That's 
unfortunate.

> That will be the case with num_get
> and money_get, but not time_get. Another problem is that the
> caller might leave the iostate variable uninitialized, and
> expect the get() member function to set it regardless of
> whether it succeeds or not. That seems to be the case with
> num_get but not the other facets.

Right.  But generally, initialization is supposed to be the 
responsibility of the owner of the object, e.g. whoever created 
it.  Compilers can generally be persuaded to warn about passing
a manifestly uninitialized variable by reference, although it's
often possible to trick them.

Nathan Myers
ncm-nospam@cantrip.org



More information about the Libstdc++ mailing list