stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Sebor <se...@roguewave.com>
Subject Re: [PATCH] punct.cpp
Date Wed, 05 Mar 2008 22:38:29 GMT
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.

I suspect we followed the original proposed resolution in our
implementation:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1350.html#231

We should have deferred implementation of the resolution until
the LWG approved it...

Martin

> 
> 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.
> 
>> FWIW, I started a page detailing out status WRT library issues
>> some time ago. The page is still very incomplete and, AFAICS,
>> doesn't mention issue 231, but I thought I should point it out
>> for future reference and use:
>> http://stdcxx.apache.org/issue_status.html
>>
>> Martin
> 
> Yet another resource that I didn't know was available. Thanks.
> 
> Travis
> 
> 
>> Travis Vitek wrote: 
>>
>>
>>> Farid Zaripov wrote:
>>>
>>>  The 22.locale.num.put.stdcxx-2 regression test fails on gcc/Linux
>>> (and I suppose that fails on every compiler on non-Windows platform).
>>>
>>>  The fail is caused when precision is 0, and in this case the 
>>> precision
>>> is not used in sprintf() format string generated by
>>> __rw_get_stdio_fmat().
>>> As a result the default precision equal to 6 is used.
>>>
>>>  As I understand the lwg issue 231 resolution, the precision 
>> should be
>>> used always for conversions from a floating-point type:
>>>
>>> 22.2.2.2.2 p5
>>> "For conversion from a floating-point type, str .precision() is
>>> specified in the conversion specification."
>>>
>>>  The proposed patch below:
>>>
>>> Index: src/punct.cpp
>>> ===================================================================
>>> --- src/punct.cpp	(revision 631177)
>>> +++ src/punct.cpp	(working copy)
>>> @@ -619,9 +619,7 @@
>>>         const int fltfld = fmtflags & _RWSTD_IOS_FLOATFIELD;
>>>
>>>         // follows resolution of lwg issue 231
>>> -        if (   (   _RWSTD_IOS_FIXED      == fltfld
>>> -                || _RWSTD_IOS_SCIENTIFIC == fltfld)
>>> -            && prec >= 0 || prec > 0) {
>>> +        if (0 <= prec) {
>>>
>>>             // 7.19.6.1, p5 of C99 specifies that, when given 
>>> using the
>>>             // asterisk, negative precision is treated the same as if
>>>
>>> Farid.
>>>
>> I haven't tested your patch, but it looks like it is 
>> consistent with the
>> resolution of WG231.
>>
>> Travis
>>
>>
>>


Mime
View raw message