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