Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: domain of Farid_Zaripov@epam.com
 designates 217.21.63.3 as permitted sender)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
Date: Tue, 25 Mar 2008 18:01:11 +0200
Message-ID: <7BDB2168BEAEF14C98F1901FD2DE643801E24031@epmsa009.minsk.epam.com>
In-Reply-To: <47E91612.3060000@roguewave.com>
Thread-Topic: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
Thread-Index: AciOipS42pxkR+RdTq67/qJaXWGl2QAA+wvg
References: <20080325143305.9337C1A9832@eris.apache.org>
 <47E91612.3060000@roguewave.com>
From: "Farid Zaripov" <Farid_Zaripov@epam.com>
To: <dev@stdcxx.apache.org>

> -----Original Message-----
> From: Martin Sebor [mailto:msebor@gmail.com] On Behalf Of Martin Sebor
> Sent: Tuesday, March 25, 2008 5:11 PM
> To: dev@stdcxx.apache.org
> Subject: Re: svn commit: r640831 - /stdcxx/trunk/include/sstream.cc
>=20
> Any idea what caused it? I've gone through the recent history=20
> of the function and this looks like the likely change might=20
> be this one:
>=20
>    http://svn.apache.org/viewvc?view=3Drev&revision=3D442675
>=20
> but the test wasn't failing. Maybe because the test doesn't=20
> cause the buffer to reallocate?

  I think the bug introduced in
http://svn.apache.org/viewvc?view=3Drev&revision=3D380995
since the overflow() and xsputn() started calling the str() for
reallocate the buffer.

rev 442675:
---------------
+    if (this->_C_is_out ()) {
+        this->setp (this->_C_buffer, this->_C_buffer +
this->_C_bufsize);
+
+        if (__s !=3D __buf || this->_C_state & (ios_base::app |
ios_base::ate))
+            this->pbump (__slen);   // seek to end
     }
---------------

 After that change setp() resets pptr to pbase, then pbump() seeks pptr
to end always,
when str() is called from xsputn() or overflow() (the str() is called to
reallocate buffer,
so __s !=3D __buf). The original position of pptr is lost.

rev 442675:
---------------
     if (this->_C_is_out ()) {
         this->setp (this->_C_buffer, this->_C_buffer +
this->_C_bufsize);
=20
-        if (__s !=3D __buf || this->_C_state & (ios_base::app |
ios_base::ate))
-            this->pbump (__slen);   // seek to end
+        if (   __s !=3D __buf && this->_C_state & ios_base::in
+            || this->_C_state & (ios_base::app | ios_base::ate)) {
+            // in input or append/ate modes seek to end
+            // (see also lwg issue 562 for clarification)
+            this->pbump (__slen);
+        }
     }
 ---------------

  After that change setp() resets the pptr to pbase, then if _C_state &
ios_base::in !=3D 0
then pbump() seeks pptr to end. In both cases the original position of
pptr is lost.

  In STDCXX-515 the stringstream is used (_C_state & ios_base::in !=3D =
0)
and subsequent
output to stream is appended to end of the buffer despite of that pptr
is not points to end
due to seek(-1), ios_base::cur).

  In STDCXX-795 the ostringstream is used (_C_state & ios_base::in =
=3D=3D 0)
and subsequent
output to stream is inserted from the begin of the buffer.

Farid.