GCC Bugzilla Bug 29035

This bug is back with gcc 4.1.1. I was told it works ok with 4.0.3


+++ This bug was initially created as a clone of Bug #9042 +++

#include <sstream>
#include <iostream>

int main() {
  std::ostringstream s("abcd", std::ios_base::app);
  s << "xy";
  std::cout << s.str() << "\n";
  // outputs "xycd" (instead of the correct "abcdxy")
}

Release:
g++ -v

Environment:
Linux, Suse 8.0
 g++ -v
Reading specs from /opt/experimental/lib/gcc-lib/i486-suse-linux/3.0.4/specs
Configured with: ../configure --enable-threads=posix --enable-long-long
--prefix=/opt/experimental
+--with-local-prefix=/usr/local --enable-languages=c,c++,f77,objc,java
--disable-nls --enable-shared
+i486-suse-linux
Thread model: posix
gcc version 3.0.4 (SuSE)

How-To-Repeat:
compile and run;

Unformatted:
 Reading specs from /opt/experimental/lib/gcc-lib/i486-suse-linux/3.0.4/specs
 Configured with: ../configure --enable-threads=posix --enable-long-long
--prefix=/opt/experimental
 +--with-local-prefix=/usr/local --enable-languages=c,c++,f77,objc,java --disa

*** This bug has been marked as a duplicate of 9042 ***

To be 100% sure, we checked again gcc4.1.1 both on x86-linux and powerc-darwin
and the bug is definitely not there (anymore)

I tried this :

#include <iostream>
#include <complex>
#include <iomanip>

using namespace std;

int main(){
        ostringstream ostr;
        ostr.str("azerty");
        cout<<ostr.tellp()<<endl;
        ostr<<"123";
        cout<<ostr.str()<<endl;
        cout<<ostr.tellp()<<endl;
 }

output is :
0
123rty
3

Where should I look at?

(In reply to comment #3)
> Where should I look at?

I don't understand what are you looking for, really. Your snippet behaves in
the correct way, per the Standard which we are implementing. Also, to repeat,
the issue reported originally in 9042 has never been reproduced on anything
newer than gcc3.2.x. In any case, please do not mix up issues (or, better said,
non-issues, so far). If, having checked the behavior mandated ISO Standard
against the behavior consistently obtained on a current gcc release, you do
find inconsistencies, please open a separate, complete of all required info,
PR. Thanks.

(In reply to comment #4)

Shouldn't the output be:

6
azerty123
9

(In reply to comment #5)
> (In reply to comment #4)
> 
> Shouldn't the output be:
> 
> 6
> azerty123
> 9

In case, that would be a separate issue, we never considered implementing that
behavior. It would be easy, of course. I don't have the standard at hand, are
you sure about that? (I will check)

(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > 
> > Shouldn't the output be:
> > 
> > 6
> > azerty123
> > 9
> 
> In case, that would be a separate issue, we never considered implementing that
> behavior. It would be easy, of course. I don't have the standard at hand, are
> you sure about that? (I will check)

I'm checking right now (I'm far from home, not able to work comfortably):
frankly, I cannot find anything in the standard mandating the alternate
behavior. For an ostringstream not opened in app-mode, of course. I find this
behavior consistent with file streams, by the way...

No, I'm not sure. I got the output with our implementation but the latest
working paper doesn't seem to support it (I had misread the text in 27.7.1.2,
p2 to require that pptr() == epptr() uncoditionally rather than just in input
mode). I'll need to check more carefully why we do what we do. Sorry for the
noise.

(In reply to comment #8)
> Sorry for the noise.

Your feedback is always welcome, really.

I think you're right. Even my own issue 562 is clear on this. I must have a bug
in the implementation of the resolution of the issue.
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-active.html#562