[PATCH] Fix libstdc++/5708

[Nathan Myers]

On Mon, Feb 18, 2002 at 05:04:44PM -0700, Martin Sebor wrote:
> Paolo Carlini wrote:
> > 
> > Nathan Myers wrote:
> > 
> > > I don't agree that we have license to assume "space" may be
> > > replaced with __fill in the output format. The subject has not (to
> > > my knowledge) been reported as a Defect to the committee. This
> > > change strikes me as a source of interoperability problems, as
> > > sensible as it might seem otherwise.
> >
> > Another thing: as Peter Schmid noticed, Nico Josuttis believes too
> > that "Where a space character has to appear, the character /fill/ is
> > inserted".
>
> It seems quite clear in the Note in 22.2.6.2.2, p2:
>
>     ...If the number of characters generated for the specified format
>     is less than the value returned by str.width() on entry to the
>     function, then copies of fill are inserted as necessary to pad to
>     the specified width. ...
>
> The Note should probably be normative, but other than that I don't
> think there's any doubt about whether it's fill that's used for
> padding.

There's no question that the fill character is to be used for padding.

At issue, however, is whether the position marked "space" in the format 
should (also) have a space.  In fact, the standard states unambiguously
that a space must appear there.  It is also clear that copies of the 
fill character are to be added, next to it, if more characters are needed 
to achieve the required width.

That is, the space is part of the "specified format", and fill characters 
are added only if that doesn't result in str.width() or more characters.

It is unfortunate that Josuttis propagates an erroneous interpretation.
I suppose that now that it has been pointed out, he will update his
"errata" page.

Nathan Myers
ncm at cantrip dot org