This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

c++/9158: ostrstream dumps core with gcc 3.1


>Number:         9158
>Category:       c++
>Synopsis:       ostrstream dumps core with gcc 3.1
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Fri Jan 03 10:06:02 PST 2003
>Closed-Date:
>Last-Modified:
>Originator:     Etienne Fréjaville
>Release:        3.1
>Organization:
>Environment:
Linux RH 7.3
>Description:
Although clearly indicated as deprecated, it is very dangerous to let compile sources with the old ostrstreams as it clearly DOESN'T WORK :

~/C++> g++ -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.1/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib
Thread model: posix
gcc version 3.1 20020604 (Red Hat Linux 7.3 3.1-5)
~/C++> cat bugostrstream.cxx 
#include <strstream.h>
main()
{
  ostrstream o;
}
~/C++> g++ bugostrstream.cxx 
In file included from /usr/include/g++-v3/backward/strstream:51,
                 from /usr/include/g++-v3/backward/strstream.h:33,
                 from bugostrstream.cxx:1:
/usr/include/g++-v3/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header. Please consider using one of the 32 headers found in section 17.4.1.2 of the C++ standard. Examples include substituting the <X> header for the <X.h> header for C++ includes, or <sstream> instead of the deprecated header <strstream.h>. To disable this warning use -Wno-deprecated.
~/C++> a.out 
Segmentation fault (core dumped)
~/C++> 

Although here the behaviour is cleary due to ostrstreams
(it fails in the destructor), I discovered that bad behaviour problem in a much more complex situation :
I had a core dump in a malloc not immediately following a free on a string returned by the str() function. (Required by the old interface).

If clearly ostrstreams (and strstreams) provoke such a behaviour, I thing that it should be much safer to
issue an ERROR at compile time rather than a WARNING.
As clearly, who can use such a class ???
Thanks for all the future users that will save time
when recompîling their code from gcc 2.96 to gcc 3.1 ...
BTW thanks for GCC it's generally quite reliable.
>How-To-Repeat:

>Fix:

>Release-Note:
>Audit-Trail:
>Unformatted:


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]