Re: Bad use of stringstream temporary?

The basic question is whether the following line of code
is legal and good (according to the current standard):

    std::string s1 =
dynamic_cast<std::stringstream&>(std::stringstream()<< "abc").str();

The problem is that "abc" gets rendered as a hex pointer
value, rather than as "abc".

This is a follow-up on my posting on the MinGW Users List.
You can find that thread, with more detail and variations
on the theme, here:

    http://thread.gmane.org/gmane.comp.gnu.mingw.user/35926

The problem is that we (or at least I) haven't been able
to identify any specific error in the code, yet three
different compilers print out the "erroneous" pointer-value
result (several versions of mingw g++, Comeau 4.3.10.1, and
msvc 9).

One speculation is that the code is illegal under the
current standard, but legal under c++0x. It is the
case that mingw g++ 4.5 and 4.6 print out the "correct"
result of "abc" when using the "-std=c++0x" option.
(mingw g++ 4.4 still prints out the "incorrect" pointer
value with "-std=c++0x".)

Here is a short test program and its output:

<< stringstream_test.cpp>>

#include<iostream>
#include<sstream>
#include<typeinfo>
int main (int argc, char *argv[]) {

   std::string s1 =
dynamic_cast<std::stringstream&>(std::stringstream()<< "abc").str();
   std::cout<< "expecting abc: "<< s1<< std::endl; // prints out
"abc" as a pointer

   std::stringstream sstr;
   std::string s2 = dynamic_cast<std::stringstream&>(sstr<<
"xyz").str();
   std::cout<< "expecting xyz: "<< s2<< std::endl;

}

C:\>g++ -o stringstream_test stringstream_test.cpp

C:\>stringstream_test
expecting abc: 0x477024
expecting xyz: xyz

That is, the two very similar test cases give different
results. The version with the unnamed temporary
stringstream prints out the "incorrect" pointer value,
while the version with the named local variable works
as expected.

(Again, more variations on this sample program that fail
to compile or give unexpected results can be found in the
thread on the MinGW Users List linked to above.)

So, is this code in error (and, if so, what's the specific
problem)? Or have we stumbled across a cluster of similar
bugs in a number of different compilers / libraries?