Re: libstdc++/3955: ostringstream behaves poorly with openmode ios::app

[Steven Barker <scbarker@uiuc.edu>]

The following reply was made to PR libstdc++/3955; it has been noted by GNATS.

From: Steven Barker <scbarker@uiuc.edu>
To: Phil Edwards <pedwards@disaster.jaj.com>
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: libstdc++/3955: ostringstream behaves poorly with openmode ios::app
Date: Tue, 7 Aug 2001 19:10:04 -0400

 --GvXjxJ+pjyke8COw
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: inline
 
 On Tue, Aug 07, 2001 at 05:12:36PM -0400, Phil Edwards wrote:
 > On Tue, Aug 07, 2001 at 07:50:43PM -0000, scbarker@uiuc.edu wrote:
 > > >Description:
 > > libstdc++ shows unexpected behavior with ostringstreams that are opened with openmode ios::app.
 > 
 > A couple of notes...
 
 <snip>
 
 > -  The current implementation examines ios_base::ate.  If that flag ("seek
 >    to the end on opening") is passed, then output begins at the end of
 >    the given string.
 
 I think that it should do the same for ios_base::app.  This would make
 it work the same way as other streams (ofstream for example).
 
 Attached is a patch to make it do that.
 
 > So, a revised version of your bug report using 3.1 CVS sources:
 
 <snip>
 
 That is a better test case.
 
 > So you see that by default we simply overwrite the given buffer, unless
 > we first seek to the end.  There are good arguments both for and against
 > overwriting the given buffer rather than appending to it (by default),
 > but I do agree that 'app' should do what you think it should.
 
 Yes, I'm not concerned with the default behavior and since there's no
 ios_base::begin value it makes sense.  
 
 > > >Fix:
 > > change the behavior of ostringstream when opened with openmode ios::app
 > 
 > You do realize, I hope, that this is a completely useless entry.  :-)
 > "Correct the problem" is not what we're looking for in the "fix" field;
 > that is implied!  An actual patch would be useful.
 
 I've attached a one line patch (to the latest CVS bits/std_sstream.h). It
 makes string_bufs treat ios_base::ate and ios_base::app the same.  It should
 work (as it is so simple a solution), but I've not tested it.
 
 -- 
 Steven Barker                                      scbarker@uiuc.edu
   The trouble with opportunity is that it always comes disguised as hard work.
   		-- Herbert V. Prochnow
 PGP Key Fingerprint: 272A 3EC8 52CE F22B F745  775E 5292 F743 EBD5 936B
 Get it at http://www.students.uiuc.edu~/scbarker/pubkey.asc
 
 --GvXjxJ+pjyke8COw
 Content-Type: text/plain; charset=us-ascii
 Content-Disposition: attachment; filename="std_sstream.h.diff"
 
 --- std_sstream.h.orig	Tue Aug  7 18:49:53 2001
 +++ std_sstream.h	Tue Aug  7 18:52:43 2001
 @@ -122,7 +122,7 @@ namespace std
  	// suite particular needs.
  	_M_buf_size_opt = 512;
  	_M_mode = __mode;
 -	if (_M_mode & ios_base::ate)
 +	if (_M_mode & (ios_base::ate | ios_base::app))
  	  _M_really_sync(0, _M_buf_size); 
  	else  
  	  _M_really_sync(0, 0);
 
 --GvXjxJ+pjyke8COw--