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)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [PATCH] punct.cpp
Date: Wed, 27 Feb 2008 14:32:39 -0700
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A499AA7C1@exchmail01.Blue.Roguewave.Com>
Thread-Topic: [PATCH] punct.cpp
Thread-Index: Ach5Wm/9SYI3Dj3cR0uMx7QM3NmhdwACXvsgAAOlD7UABNY2IA==
References: <7BDB2168BEAEF14C98F1901FD2DE643801B84211@epmsa009.minsk.epam.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7C0@exchmail01.Blue.Roguewave.Com>
 <CFFDD219128FD94FB4F92B99F52D0A49012DD997@exchmail01.Blue.Roguewave.Com>
From: "Travis Vitek" <Travis.Vitek@roguewave.com>
To: <dev@stdcxx.apache.org>

=20

>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:=20
>=20
>
>>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=20
>>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=20
>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
>>=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>--- src/punct.cpp	(revision 631177)
>>+++ src/punct.cpp	(working copy)
>>@@ -619,9 +619,7 @@
>>         const int fltfld =3D fmtflags & _RWSTD_IOS_FLOATFIELD;
>>=20
>>         // follows resolution of lwg issue 231
>>-        if (   (   _RWSTD_IOS_FIXED      =3D=3D fltfld
>>-                || _RWSTD_IOS_SCIENTIFIC =3D=3D fltfld)
>>-            && prec >=3D 0 || prec > 0) {
>>+        if (0 <=3D prec) {
>>=20
>>             // 7.19.6.1, p5 of C99 specifies that, when given=20
>>using the
>>             // asterisk, negative precision is treated the same as if
>>
>>Farid.
>>
>
>I haven't tested your patch, but it looks like it is=20
>consistent with the
>resolution of WG231.
>
>Travis
>
>
>