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

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

[Steven Barker]

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

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

[pme]

Synopsis: ostringstream behaves poorly with openmode ios::app

Responsible-Changed-From-To: unassigned->pme
Responsible-Changed-By: pme
Responsible-Changed-When: Sun Mar  3 09:54:21 2002
Responsible-Changed-Why:
    Mine.
State-Changed-From-To: open->closed
State-Changed-By: pme
State-Changed-When: Sun Mar  3 09:54:21 2002
State-Changed-Why:
    Sorry this took so long...  this is fixed for 3.1 and
    later releases.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=3955

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

[Phil Edwards]

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

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

 On Tue, Aug 07, 2001 at 07:10:04PM -0400, Steven Barker wrote:
 > 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.
 
 Good, that's the same change I have in my local tree.  I still need to
 write up a testcase, and get feedback from the others.
 
 Phil
 
 -- 
 Would I had phrases that are not known, utterances that are strange, in
 new language that has not been used, free from repetition, not an utterance
 which has grown stale, which men of old have spoken.
                                      - anonymous Egyptian scribe, c.1700 BC

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

[Phil Edwards]

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

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

 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...
 
 -  ios::app (now called ios_base::app) is completely ignored by the
    standard and by our implementation, as far as stringbuf goes.  It makes
    no difference whatsoever.
 
 -  I've looked through the LWG's issues lists, the libstdc++ mailing list
    archives, and the newsgroup archives.  I can't find any discussion of how
    [o]stringstreams are supposed to behave when given openmode parameters
    other than ios_base::in and ios_base::out.
 
    I would want to hear the intentions of the designers before making any
    changes (it's obvious that some kind of change is needed).
 
 -  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.
 
 So, a revised version of your bug report using 3.1 CVS sources:
 
     1% cat 3955.cc
     #include <iostream>
     #include <sstream>
 
     int main()
     {   
        std::ostringstream no_options ("foobar");
        std::ostringstream with_app   ("foobar", std::ios_base::app);
        std::ostringstream with_ate   ("foobar", std::ios_base::ate);
 
        no_options << "baz";
        with_app << "baz";
        with_ate << "baz";
 
        std::cout << "no_options:\t" << no_options.str() << std::endl;
        std::cout << "with_app:\t" << with_app.str() << std::endl;
        std::cout << "with_ate:\t" << with_ate.str() << std::endl;
     }
     2% g++ 3955.cc
     3% ./a.out 
     no_options:	bazbar
     with_app:	bazbar
     with_ate:	foobarbaz
     4% 
 
 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.
 
 
 > >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.
 

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

[scbarker]

>Number:         3955
>Category:       libstdc++
>Synopsis:       ostringstream behaves poorly with openmode ios::app
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Aug 07 12:56:00 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator:     Steven Barker
>Release:        3.0.1 20010801 (Debian prerelease) and 2.95.4 20010721 (Debian prerelease)
>Organization:
>Environment:
Debian GNU/Linux 2.4.4 i^86 unstable
>Description:
libstdc++ shows unexpected behavior with ostringstreams that are opened with openmode ios::app.

A testcase is attached, who's output should be
foobarbaz

with gcc 3.0.1 20010801 the output is
bazbar

with gcc 2.95.4 20010721 the output is
baz
>How-To-Repeat:
compile and execute attached testcase
>Fix:
change the behavior of ostringstream when opened with openmode ios::app

workaround: open with ios::ate (or ios::ate | ios::app if there's any difference)
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="bugtest.cc"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="bugtest.cc"

I2luY2x1ZGUgPGlvc3RyZWFtPgojaW5jbHVkZSA8c3N0cmVhbT4KCmludCBtYWluKCkKeyAgIAog
ICBzdGQ6Om9zdHJpbmdzdHJlYW0gYmFyKCJmb29iYXIiLCBzdGQ6Omlvczo6YXBwKTsKICAgCiAg
IGJhciA8PCAiYmF6IjsKICAgCiAgIHN0ZDo6Y291dCA8PCBiYXIuc3RyKCkgPDwgc3RkOjplbmRs
Owp9Cg==