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: multipart/alternative;
	boundary="----_=_NextPart_001_01C87974.200BF3A1"
Subject: RE: [PATCH] punct.cpp
Date: Wed, 27 Feb 2008 12:08:24 -0700
Message-ID: 
 <CFFDD219128FD94FB4F92B99F52D0A49012DD997@exchmail01.Blue.Roguewave.Com>
Thread-Topic: [PATCH] punct.cpp
Thread-Index: Ach5Wm/9SYI3Dj3cR0uMx7QM3NmhdwACXvsgAAOlD7U=
References: <7BDB2168BEAEF14C98F1901FD2DE643801B84211@epmsa009.minsk.epam.com>
 <CFFDD219128FD94FB4F92B99F52D0A499AA7C0@exchmail01.Blue.Roguewave.Com>
From: "Martin Sebor" <sebor@roguewave.com>
To: <dev@stdcxx.apache.org>, <dev@stdcxx.apache.org>

------_=_NextPart_001_01C87974.200BF3A1
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

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.

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

-----Original Message-----
From: Travis Vitek [mailto:Travis.Vitek@roguewave.com]
Sent: Wed 2/27/2008 10:54 AM
To: dev@stdcxx.apache.org
Subject: RE: [PATCH] punct.cpp
=20
=20

>From: Farid Zaripov [mailto:Farid_Zaripov@epam.com]=20
>Subject: [PATCH] punct.cpp
>
>  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 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 consistent with the
resolution of WG231.

Travis


------_=_NextPart_001_01C87974.200BF3A1--