[Bug libstdc++/26250] stringbuf::overflow() fails to set egptr() same as epptr()

["sebor at roguewave dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #4 from sebor at roguewave dot com  2006-02-13 18:12 -------
(In reply to comment #3)
[...]
> keeping get area and put area separate as much as possible (consistently with
> filebuf, by the way): this implies not only that egptr() is not updated to
> "match" epptr() upon overflow, but also that, really, doesn't make much sense
> talking about it during output. In fact, when input will start, and epptr()
> will be finally updated to match reality (i.e., the length of the internal
> string) in underflow, almost certainly will not match epptr() anyway.

Yes. But that doesn't conform to the requirement in 27.7.1.3, p8:

  ...If (mode & ios_base::in) != 0, the function alters the read end pointer
  egptr() to point just past the new write position (as does the write end
  pointer epptr()).

I'm not sure it makes sense yet, but it's there nonetheless. DR 169 doesn't
lift the requirement, it just allows overflow() to make more than one write
position available. Maybe we need a new issue to permit the behavior
implemented by libstdc++.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250