[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag

2010-09-09 Thread redi at gcc dot gnu dot org 


--- Comment #1 from redi at gcc dot gnu dot org  2010-09-09 19:19 ---
this isn't specific to strstreams

#include iostream
#include sstream
using namespace std;

int main()
{
stringstream io;

io.ios::fill('@');
io.flags(ios::internal);
io.width( 10 );
io  (void *) 123  ' ';
cout  String:   io.str()  endl;
}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618

[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag

2010-09-09 Thread paolo dot carlini at oracle dot com 


--- Comment #2 from paolo dot carlini at oracle dot com  2010-09-09 19:59 
---
The output seems perfectly fine to me: at the end of Stage 1 we have 0x7b,
exactly what one gets from printf(%p, (void*)123), per 22.2.2.2.2/12, then,
per Table 61, padding is added after x, thus 0x@@7b.


-- 

paolo dot carlini at oracle dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618

[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag

2010-09-09 Thread anhtuyen at ca dot ibm dot com 


--- Comment #3 from anhtuyen at ca dot ibm dot com  2010-09-09 20:12 ---
(In reply to comment #2)
 The output seems perfectly fine to me: at the end of Stage 1 we have 0x7b,
 exactly what one gets from printf(%p, (void*)123), per 22.2.2.2.2/12, then,
 per Table 61, padding is added after x, thus 0x@@7b.
 


Using the ios::internal flags, the format has changed from @@0x7b (gcc
4.1.2) to 0x@@7b (gcc 4.4.4) . One of them must be incorrect, at the very
least.


-- 

anhtuyen at ca dot ibm dot com changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|INVALID |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618

[Bug c++/45618] GCC 4.4.4 strstream and ios::internal flag

2010-09-09 Thread redi at gcc dot gnu dot org 


--- Comment #4 from redi at gcc dot gnu dot org  2010-09-09 20:23 ---
See Table 61 in C++ 2003 (or table 88 in C++0x draft) - the 4.4 behaviour is
correct


-- 

redi at gcc dot gnu dot org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45618