I've recently noticed some non-conformant behavior in formatting char
const* (operator<<) both in g++ 3.1 and Sun CC 5.2.  I suspect that in
fact, these compilers are doing what was really intended, and that the
wording in the standard is wrong.

The problem concerns the padding of strings: both char const*
(   27.6.2.5.4 [lib.ostream.inserters.character]/4) and std::string
(   21.3.7.9 [lib.string.io]/4) are concerned.  In both cases, the
standard says "padding as described in stage 3 of 22.2.2.2.2" or
"padding is determined as described in 22.2.2.2.2".

In    22.2.2.2.2 [lib.facet.num.put.virtuals]/19, we find table 61, which
specifies that:

    adjustfield == internal and a       pad after the sign
    sign occurs in the representation

    adjustfield == internal and rep-    pad after x or X
    resentation after stage 1 began
    with 0x or 0X

According to this, the following code :

    char const*         s = "0XYZ" ;
    cout.setf( ios::internal , ios::adjustfield ) ;
    cout << "|" << setw( 10 ) << s << "|\n" ;

should output:
    |0X      YZ|
and not:
    |      0XYZ|
as it does with the compilers I have access to.

I can't imagine this being an enormous problem, but it can intervene in
things like:

    log << "Error: abc=" << hexFmt( 4 ) << abc << "-- unexpected value\n" ;

where "hexFmt" is a manipulator which sets basefield to hex, but also
width to its parameter, fill to '0', and showbase and internal in the
fmtflags.

I suspect that the behavior defined be the standard is not what was
really wanted, and that the two compilers I have tried are closer to the
actual intent.  (I wonder what Dinkumware does in this case.)

If this is true, then I suggest that the wording of the sentences in
[lib.ostream.inserters.character] and [lib.string.io] cited above be
changed to say "padding occurs as defined in stage 3 of 22.2.2.2.2,
except that adjustfield == ios_base::internal is ignored."

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

kanze@gabi-soft.de (James Kanze) writes:

> If this is true, then I suggest that the wording of the sentences in
> [lib.ostream.inserters.character] and [lib.string.io] cited above be
> changed to say "padding occurs as defined in stage 3 of 22.2.2.2.2,
> except that adjustfield == ios_base::internal is ignored."

Ignored in the sense of treating it as ios_base::left or in the sense
of treating it as ios_base::right?
(FWIW, All the implementations I have to hand treat it as if it were
ios_base::right - which concurs with the "otherwise" case in table 61.

Regards,
 Andy S.
--
"Light thinks it travels faster than anything but it is wrong. No matter
 how fast light travels it finds the darkness has always got there first,
 and is waiting for it."                  -- Terry Pratchett, Reaper Man

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

andys@evo6.com (Andy Sawyer) wrote in message
news:<y99f656a.fsf@ender.evo6.com>...
> kanze@gabi-soft.de (James Kanze) writes:

> > If this is true, then I suggest that the wording of the sentences in
> > [lib.ostream.inserters.character] and [lib.string.io] cited above be
> > changed to say "padding occurs as defined in stage 3 of 22.2.2.2.2,
> > except that adjustfield == ios_base::internal is ignored."

> Ignored in the sense of treating it as ios_base::left or in the sense
> of treating it as ios_base::right?

Ignored in the sense of acting as if the corresponding table entries
weren't there.

> (FWIW, All the implementations I have to hand treat it as if it were
> ios_base::right - which concurs with the "otherwise" case in table 61.

Well, if interal is set, then left and right aren't.  So if you ignore
the entries for internal, and left and right aren't set, you end up in
the otherwise case.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]