------- Comment #3 from pcarlini at suse dot de 2006-02-13 10:59 ------- (In reply to comment #2) > This means that we are updating epptr() in underflow, not earlier, not upon > overflow. Does this way of implementing DR 169 make sense to you?
I want to avoid giving the wrong impression that is only matter of "when". In fact, our (mine and Nathan's, at least) best interpretation of DR 169 implies 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250
