incubator-stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Travis Vitek" <Travis.Vi...@roguewave.com>
Subject RE: [PATCH] punct.cpp
Date Wed, 05 Mar 2008 19:52:20 GMT
 

>Travis Vitek wrote:
>
>>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
>

I took the time to look at this, and I think 22.locale.num.put.cpp is
wrong given the resolution of LWG231. Here are a few of the failing
assertions from 22.locale.num.put...

    //        +-- value to format
    //        |     +-- fmtflags
    //        |     |  +-- precision
    //        |     |  |  +-- field width
    //        |     |  |  |   +-- fill character
    //        |     |  |  |   |   +-- grouping
    //        |     |  |  |   |   |   +-- expected output
    //        |     |  |  |   |   |   |
    //        V     V  V  V   V   V   V

    TEST (T,  1.1,  0, 0, 0, ' ', "", "%g");
    TEST (T,  1.1,  0, 0, 0, ' ', "", "1.1");
    TEST (T, -1.1,  0, 0, 0, ' ', "", "%g");
    TEST (T, -1.1,  0, 0, 0, ' ', "", "-1.1");

    TEST (T,  0.0L, 0, 0, 0, ' ', "", "%Lg");
    TEST (T,  1.0L, 0, 0, 0, ' ', "", "%Lg");
    TEST (T,  2.1L, 0, 0, 0, ' ', "", "%Lg");
    TEST (T, -3.2L, 0, 0, 0, ' ', "", "%Lg");
    TEST (T, -4.3L, 0, 0, 0, ' ', "", "%Lg");
    // there are more...

Notice that the precision field value is 0 in the above cases. The
resolution for LWG231 says that for floating point types,
str.precision() is always used in the conversion specification. So each
of the above tests would need to take this into account.

We are currently consistent with several other implementations. I don't
believe that either of them implement the LWG231 resolution. The GNU
implementation does implement the new behavior.

Travis




Mime
View raw message