libstdc++/2832: rdbuf methods incorrect
kenny.simpson@gs.com
kenny.simpson@gs.com
Tue May 15 13:36:00 GMT 2001
>Number: 2832
>Category: libstdc++
>Synopsis: rdbuf methods incorrect
>Confidential: no
>Severity: serious
>Priority: medium
>Responsible: unassigned
>State: open
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Tue May 15 13:36:01 PDT 2001
>Closed-Date:
>Last-Modified:
>Originator: kenny.simpson@gs.com
>Release: 20010507 snapshot
>Organization:
>Environment:
>Description:
The rdbuf methods of the fstream and stringstream classes seem wrong.
For each of these classes they return a casted version of _M_streambuf.
The problem is that the fstream and stringstream classes should
contain a real stringbuf or filebuf member and that is what their
rdbuf() methods should return a pointer to.
Calling rdbuf( std::streambuf* ) changes the _M_streambuf pointer
like it should, but this should not affect the return of the
rdbuf() methods of stringstream and fstream.
What's worse is that because of this, the destructors and
member functions of fstream and stringstream treat the
_M_streambuf as a pointer to their own internal buffer.
The destuctors delete the buffer even though the buffer may
not be owned by the object.
The member functions call methods on _M_streambuf that may
not exist.
>How-To-Repeat:
#include <iostream>
#include <ios>
#include <iosfwd>
#include <sstream>
#include <cassert>
void redirect( std::streambuf* new_buf, std::ios& stream )
{
stream.rdbuf( new_buf );
}
int main()
{
std::stringstream str1;
std::stringbuf* const buf = str1.rdbuf();
redirect( std::cout.rdbuf(), str1 );
str1 << "hello\n"; // should send "hello" to stdout
assert( buf == str1.rdbuf() ); // this should never change
return 0;
}
>Fix:
1. Make fstreams and stringstreams contain a real internal buffer.
2. Have rdbuf() return a pointer to that buffer.
3. Change the destructors to not delete rdbuf(), but only destroy
their local buffers (i.e. do nothing, let the default destructor
do the right thing)
>Release-Note:
>Audit-Trail:
>Unformatted:
More information about the Gcc-bugs
mailing list