The following num_put<> member function iter_type do_put(iter_type out, ios_base& str, char_type fill, const void* val) const incorrectly performs padding of a string to bring its length to the required value if 'adjustfield' flag is equal to 'internal': instead of adding fill characters after "0x" it adds them at the beginning of the string According to the description of padding options (22.2.2.2.2 p19), if adjustfield == internal and representation after stage 1 began with 0x or 0X - pad after x or X. Example: #include <iostream> #include <locale> using namespace std; int main() { void *p = (void*)0x1; cout.width(5); cout << internal << p << endl; return 0; } output " 0x1" while it should be "0x 1"
Yes.
Subject: Bug 38210 Author: paolo Date: Fri Nov 21 09:59:17 2008 New Revision: 142085 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=142085 Log: 2008-11-21 Paolo Carlini <paolo.carlini@oracle.com> PR libstdc++/38210 * include/bits/locale_facets.tcc (num_put<>::do_put(iter_type, ios_base&, char_type, const void*)): Fix. * testsuite/22_locale/num_put/put/char/38210.cc: New. * testsuite/22_locale/num_put/put/wchar_t/38210.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/22_locale/num_put/put/char/38210.cc trunk/libstdc++-v3/testsuite/22_locale/num_put/put/wchar_t/38210.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/locale_facets.tcc
Fixed for 4.4.0.
On *-apple-darwin9, the following tests are now failing: FAIL: 22_locale/num_put/put/char/38210.cc execution test FAIL: 22_locale/num_put/put/wchar_t/38210.cc execution test
Apparently the failures I have reported in comment #4 disappear if I rebuild libstdc++. Sorry for the noise.
(In reply to comment #5) > Apparently the failures I have reported in comment #4 disappear if I rebuild > libstdc++. Not surprising ;)