>Travis Vitek wrote: > >>Martin Sebor wrote: >> >>I don't have the time to do a careful review of the patch WRT >>the LWG issue at the moment but I note there's a comment above >>the code that's being modified that references the issue, so >>it looks like the current code already tries to handle it. If >>it does so successfully or not I can't say without spending >>more time on it. > >Here is a quote from the resolution... > > For conversion from a floating-point type, str.precision() > is specified in the conversion specification. > >The following is taken from the comments following that... > > The floatfield determines whether numbers are formatted as > if with %f, %e, or %g. If the fixed bit is set, it's %f, if > scientific it's %e, and if both bits are set, or neither, > it's %g. > > Turning to the C standard, a precision of 0 is meaningful > for %f and %e. For %g, precision 0 is taken to be the same > as precision 1. > >Previously, if the precision was 0 and floatfield was not >fixed or scientific [i.e. %g] we wouldn't apply precision >format string at all. According to this, we should apply >precision 0 and assume that the printf() family correctly >handles this case, or force precision to 1. >
I've tested the patch on AIX, and it fixes failure of regression test 22.locale.num.put.stdcxx-2. Unfortunately it causes an additional 22 assertions to fail in 22.locale.num.put. Travis
