Archived

This topic is now archived and is closed to further replies.

Kylotan

Anyone else get this ostringstream bug in VC6?

Recommended Posts

(Or maybe it''s just my compiler or library.) Minimal test case:
  
#include <sstream>
using namespace std;

int main()
{
    ostringstream strm;

    strm.str("abcd");
    strm << 123;
    strm.str("efgh"); // Crashes here


    return 1;
}
  
My guess is that the first const char buffer passed to the stream with str is being written to by the line that inserts 123 to the stream. But this would be incorrect behaviour, as str() should take a copy of the string it is passed, not the string itself (and therefore, not the char* itself). It doesn''t crash if I take out the insertion line in the middle. It also doesn''t crash if I give it a stringstream rather than an ostringstream: but surely that shouldn''t make a difference. str(string) is well defined for both types of string, as far as I can tell. So firstly, is this just me? And if not, is this a bug in the library or in my understanding? [ MSVC Fixes | STL | SDL | Game AI | Sockets | C++ Faq Lite | Boost ]

Share this post


Link to post
Share on other sites
I reproduced the crash with a slight variation; when I made the first string longer than 4 characters. For me, it is not crashing, but getting a memory debug assert when applying the destructor. Took a quick look, but nothing jumped out at me.

The source for this object is on the MSVC++ 6.0 disk, under VC98 (at least on my version). Might take some involved debugging to figure it out. Looks very odd.

Share this post


Link to post
Share on other sites
''k, I''m confused on the difference between ostringstream and istringstream.

I thought ostringstream is used like so:
oss << "take " << 1 << "and call me in the morning" << endl;
throw runtime_error (oss.str ()); // output

and istringstream was used like so:
iss.str ("Take 1 and call me in the morning");
iss >> str1 >> int1 >> str2;

So I thought the str () method was const in one and not in the other, but according to the docs I have that''s not so. Of course, we''ve found a whole slew of things in the MSVC headers that aren''t standard compliant lately.

Share this post


Link to post
Share on other sites
Kylotan:

  
#include <iostream>
#include <sstream>
 
using namespace std;
 
int main ()
{
ostringstream out;
 
out.str ("abcd");
out << 123;
out.str ("efgh");
 
cout << out.str () << endl;
 
return 0;
}


Works fine for me. It outputs "efgh" without crashing. It must be your setup. I''m using MSVC 6.0 SP5 w/ August 2001 Platform SDK on Windows XP Home Edition.


Stoffel:

  
// Theses are simplified declarations, but useful...

 
std:: stringstream::str (const string& s);
std::istringstream::str (const string& s);
std::ostringstream::str (const string& s);


The old style string streams (strstream) operated on a buffer supplied by the user, whereas the new style string streams (stringstream) create a string with that value of your string and operate on the copy''s buffer.

Share this post


Link to post
Share on other sites
Oh, I just remembered I hit the execute button instead of go. Hitting the go button results in a debug assertion. The constant string is being copied to an allocated buffer (in std::basic_stringbuf::_Init), and being cleaned up (in std::basic_stringbuf::_Tidy). I see no reason why it should cause a debug assertion.

Edited by - null_pointer on February 6, 2002 3:03:22 PM

Share this post


Link to post
Share on other sites
Ok, so at the moment, it''s looking like a bug in the MSVC library implementation. Anyone else have any results from MSVC6? And can anyone comment on whether the behaviour of str(string) for an ostringstream is well defined or not? If I get a few more confirming that it crashes needlessly, I''ll file a bug report with the library developer.

Share this post


Link to post
Share on other sites
I looked a little more, and it seems that it keeps some sort of previous version of the string value. In the destructor, it tries to free it up, but it already freed it up in Tidy() (called when the second ''str'' call it made). Seems it is not ready for more than one ''initialization'' (internally, a call to its Init() function).

Definitely looks like a bug to me.

Share this post


Link to post
Share on other sites
Visual Studio 7.0, including the fabulous (*cough*sarcasm*cough*) .NET architecture. I AM looking forward to the new C++ compiler though.


People might not remember what you said, or what you did, but they will always remember how you made them feel.

Share this post


Link to post
Share on other sites