Re: [PATCH] Fix libstdc++/5708

[Nathan Myers <ncm-nospam at cantrip dot org>]

On Mon, Feb 18, 2002 at 07:48:28PM -0700, Martin Sebor wrote:
> Nathan Myers wrote:
> > > 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.
> 
> It didn't occur to me that the two could be treated differently,
> especially since the Note in 22.2.6.2.2, p2 goes on to say:
> 
>     ...For the value af equal to (str.flags() & str.adjustfield),
>     if (af ==str.internal) is true, the fill characters are placed
>     where none or space appears in the formatting pattern; ...
> 
> Or am I still missing something?

I don't know.  It seems perfectly clear to me that one part of the
document says that a space appears in the format, and a different part 
of the document describes adding fill characters if the format _including_
the space isn't long enough.  I don't see any text saying to take the 
space out, or to replace it with one or more fill characters.  It just
says where to insert your fill characters.

I agree that it may not be clear enough whether the fill character goes
before or after the space, if one is specified.  (Given the semantics 
of std::string insertion, which specify an insert position as the index
of the character that ends up following the inserted text, a defensible
choice would be to put them before the space.)  If the fill character 
isn't actually a space, you may not be able to parse the result back in,
but that's noted in the standard already. 

Nathan Myers
ncm at cantrip dot org