Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@stdcxx.apache.org
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <47CF256A.3030709@roguewave.com>
Date: Wed, 05 Mar 2008 15:57:46 -0700
From: Martin Sebor <sebor@roguewave.com>
Organization: Rogue Wave Software, Inc.
User-Agent: Thunderbird 2.0.0.12 (X11/20080226)
MIME-Version: 1.0
To: dev@stdcxx.apache.org
Subject: Re: [PATCH] punct.cpp
References: <7BDB2168BEAEF14C98F1901FD2DE643801B84211@epmsa009.minsk.epam.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7C0@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49012DD997@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7C1@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7CC@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7CD@exchmail01.Blue.Roguewave.Com>
In-Reply-To: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA7CD@exchmail01.Blue.Roguewave.Com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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

Here's the full set I get for num_put<char> on AIX 5.3:

$   ./22.locale.num.put  --no-wchar -q --csv \
   | cut -d, -f5- | sed "s/num_put<char>:://"
  1729, "line 377: put (..., double = 1.1) wrote ""1"", expected ""1.1"""
  1730, "line 377: put (..., double = 1.1) wrote ""1"", expected ""1.1"""
  1731, "line 377: put (..., double = -1.1) wrote ""-1"", expected ""-1.1"""
  1732, "line 377: put (..., double = -1.1) wrote ""-1"", expected ""-1.1"""
  1817, "line 377: put (..., long double = 2.1) wrote ""2"", expected 
""2.1"""
  1818, "line 377: put (..., long double = -3.2) wrote ""-3"", expected 
""-3.2"""
  1819, "line 377: put (..., long double = -4.3) wrote ""-4"", expected 
""-4.3"""
  1829, "line 377: put (..., long double = 255) wrote ""3e+02"", 
expected ""255"""
  1830, "line 377: put (..., long double = 255) wrote ""3e+02"", 
expected ""255"""
  1831, "line 377: put (..., long double = 127) wrote ""1e+02"", 
expected ""127"""
  1832, "line 377: put (..., long double = 32767) wrote ""3e+04"", 
expected ""32767"""
  1833, "line 377: put (..., long double = 65535) wrote ""7e+04"", 
expected ""65535"""
# +-----------------------+----------+----------+----------+
# | DIAGNOSTIC            |  ACTIVE  |   TOTAL  | INACTIVE |
# +-----------------------+----------+----------+----------+
# | (S1) INFO             |       49 |       49 |       0% |
# | (S2) NOTE             |        2 |        2 |       0% |
# | (S5) WARNING          |        1 |        1 |       0% |
# | (S7) ASSERTION        |       12 |      852 |      98% |
# +-----------------------+----------+----------+----------+

> 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.

Yes, although it's not immediately obvious to me what the problem
is, The first assertion above corresponds to this line:

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

I don't see where the test ends up formatting 1.1 as 1.1 using the
"%g" directive (on AIX, printf("%g", 1.1) produces 1 as expected.

Martin

> 
> 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
> 
> 
>