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, 27 Feb 2008 21:32:39 GMT
 

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

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