This is the mail archive of the libstdc++@gcc.gnu.org mailing list for the libstdc++ project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] Fix libstdc++/5708


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?

Martin


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]