This content has been marked as final. Show 3 replies
I don't see anything obviously wrong with your code, so you appear to have run into an issue with the default libCstd used with the compiler. The optional STLport library fails with a runtime abort, but the optional Apache stdcxx library (available on Solaris 10u10 and Solaris 11) does not have a problem.
If you have a service contract with Oracle, please file a bug report via your support channel. Otherwise, please file a bug report at http://bugs.sun.com
BTW, please use "code" tags when posting source code, scripts, or compiler output. The tags preserve the code format, and prevent the Forum software from interpreting special characters as formatting directives.
The standard says:
22.214.171.124 pt. 3The implementation from libCstd sets <tt>badbit</tt> and <tt>rdbuf() == 0</tt> (check that, add <tt><< static_cast<void*>(filestream.rdbuf())</tt>). This is because <tt>basic_ostream</tt> constructor checks if sb has the mode bit <tt>ios_base::out</tt> set and installs null buffer if it is cleared.
postconditions of <tt>basic_ios::init(basic_streambuf* sb)</tt>
<tt>rdbuf()</tt> == sb
<tt>rdstate()</tt> == <tt>goodbit</tt> if sb is not a null pointer, otherwise <tt>badbit</tt>
<tt>basic_ostream::basic_ostream(basic_streambuf* sb)</tt> constructs an object of class <tt>basic_ostream</tt>, assigning initial values to the base class by calling <tt>basic_ios::init(</tt>sb<tt>)</tt>
postcondition: <tt>rdbuf() == </tt>sb
This is not standard-conformant but helped find a real problem with your code (this is not 100% libCstd fault). Its behaviour is definitely not well defined:
<tt>mystream</tt> constructor provides the base class with an not yet initialized <tt>m_buffer</tt>. This is because base class (<tt>basic_ostream</tt>) constructor gets called before <tt>m_buffer</tt>'s constructor. So the <tt>mode_</tt> member of <tt>m_buffer</tt> tested in <tt>basic_ostream</tt> constructor has yet undefined value which happens to have <tt>ios_base::out</tt> bit set when <tt>foo</tt> is excluded and cleared otherwise.
I cannot figure out how the <tt>foo</tt> member influences initial (i.e. not-yet-constructed) value of <tt>mode_</tt> member of the buffer