Re: An even better implementation of 22.2.6.2.2 ??

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

Apologies for the delay...

On Tue, Feb 19, 2002 at 11:20:40PM +0100, Paolo Carlini wrote:
> Benjamin Kosnik wrote:
> 
> > Nathan I'd like to see proposed wording from you before this gets
> > changed again.
> >
> > Martin proposed wording here:
> > http://gcc.gnu.org/ml/libstdc++/2002-02/msg00161.html
> 
> Indeed, I have just noticed (sorry) that in Martin final proposed
> wording the required space is *after* the fill characters (I thought
> that in yesterday's discussion you all mostly agreed for the required
> space *before* the fill characters).

Before we get into opinions, let me summarize:

1. The standard is clear that if the format pattern contains a "space",
   then the resulting character sequence includes an actual space
   character.

2. The standard is clear that if the width requires padding, the fill()
   characters are placed adjacent to this space (if any).

3. Various implementers (apparently including Dinkumware, Metrowerks, 
   and Rogue Wave) have misread the standard and shipped nonconforming
   variations, such as omitting the space when the currency symbol is 
   suppressed, or using the fill character in place of the space.

4. The standard is entirely mute on the subject of whether the fill
   characters (if any) appear before or after the space (if any).

If we are only interested in conformance, it is easy: insert a space
where indicated, and choose arbitrarily whether to insert fill characters
before it or after it.  

Interoperability is harder.  The monetary formats were meant to be 
strictly specified because interpretation errors where monetary values 
are involved could cause big trouble.  Too much slack in the spec would 
be a defect by that criterion.  Can a user write code that will generate 
output that can safely be read by any other implementation?  If the fill 
character is other than (' '), there is no expectation anyhow.  If the 
fill character is (' '), then it doesn't matter whether they appear before
or after the required space.

The Internet guideline: "be strict in what you send, liberal in what 
you accept" may help a bit with compatibility with nonconforming 
implementations, once we know what nonconformances are common.
However, this is hazardous if it might lead to silently misreading
monetary values.

Is the specification to insert a space, rather than the fill character,
a defect?  Probably not.  It's part of the portable format.  It would
seem OK to substitute the fill character because the format is only 
portably readable if any fill characters inserted are spaces.  However, 
if the user hasn't specified a width, they would have no reason to 
make sure that the fill character was a space, because they would not
expect it to be used.

Is the requirement to emit the space even when there is no currency 
symbol a defect?  Probably.  The space (where the locale specifies one) 
is associated with the currency symbol in the monetary format in the C 
library; this matters because the behavior of the C library determines
what appears in the locale files used by the C++ library.

Is the underspecification of where to place the fill characters a defect?
Probably.  In practice, if the fill character isn't a space, you always 
want the fill characters next to the numeric value, so the placement 
probably should vary according to the actual format.  Usually if the
fill character isn't a space, it's zero, or a marker character like "*"
to make it harder to forge extra digits by hand.

We should prepare a Defect Report for the committee.  Of course there's
no telling what they will do with it, but usually they will either say 
"not a defect", blessing all interpretations, or pick one to bless.

Nathan Myers
ncm at cantrip dot org