------- Comment #5 from pcarlini at suse dot de 2006-02-13 18:20 ------- (In reply to comment #4) > 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.
I see what you mean. The problem is that DR 169 says that: "Of course, the resolution below requires some handling of simultaneous input and output since it is no longer possible to update egptr() whenever epptr() is changed. A possible solution is to handle this in underflow()." but then, doesn't change 27.7.1.3, p8, as it should, in my opinion, because the rationale is exactly that. Maybe we need a new issue to permit the behavior > implemented by libstdc++. I would like that ;) Seriously, I think it's already *in* DR 169, only should be clearly stated, as a change to 27.7.1.3, p8. I don't know which is the best way to proceed... (by the way, again, Dinkum delivered with ICC also fails the last assert) -- pcarlini at suse dot de changed: What |Removed |Added ---------------------------------------------------------------------------- AssignedTo|pcarlini at suse dot de |unassigned at gcc dot gnu | |dot org Status|WAITING |NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26250