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