Topic: bug in istream::getline?


Author: Nathan Myers <ncm@netcom.com>
Date: 1995/12/10
Raw View
> >>>>> "CB" == Christopher Barber <cbarber@bbn.com>:
> >>>>> "BE" == Bernd Eggink <admin@rzaix13.uni-hamburg.de>:
>
>   CB> I have derived a new class from streambuf and overloaded most of the
>   CB> virtual protected members (overflow, underflow, xsgetn, xsputn, etc)
>   CB> but do not touch the stream pointer methods (setg, gbump, setp, etc)
>   CB> and as far as I understand the standard I don't need to.
>
>   BE> You MUST call setp() and segp() from within your functions
>   BE> overflow() and underflow() in order to set up the put/get area and
>   BE> reflect the fact that the put area is now empty and ready to be
>   BE> filled again, rsp. that the get area has been filled from the
>   BE> source and characters may now be extracted.

Christopher Barber replied:
> Creating a single character get area and pointing the get pointers fixed my
> problem.  I can see why this is necessary for reads since a successful
> return from underflow() essentially implies that gnext is valid.
>
> However, in the case of writes, I see no reason that one is required to
> call setp().  As far as I can see, there are no functions that guarantee
> that there will be a position available in the put buffer.  So if you never
> call setp(), the pointers will always be null and ostream routines will
> just keep calling overflow() or xsputn().  Once again, have I overlooked
> something in the standard?

I believe Bernd is wrong.  Also, I don't think a successful return from
underflow() implies anything extra about the values of the pointers.

The condition of all the pointers being null is a legal streambuf state,
and the nonvirtual functions (e.g. the getline()) member) are expected
to call a virtual if they encounter it.  An implementation where this
doesn't happen, under some condition, is just buggy.  (Please report this
to the gnu people...)

Derivation from streambuf, or from std::basic_streambuf<>, is an
unfortunately tricky business.  For example, the most derived class
is responsible for calling sync() at destruction time; the base class
destructors can't help (and ~streambuf() itself won't try).

Nathan Myers
myersn@roguewave.com

[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]