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. ]