[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 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.
RE: [PATCH] punct.cpp
>From: Farid Zaripov [mailto:[EMAIL PROTECTED]
>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
>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
RE: [PATCH] punct.cpp
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:[EMAIL PROTECTED]
Sent: Wed 2/27/2008 10:54 AM
To: dev@stdcxx.apache.org
Subject: RE: [PATCH] punct.cpp
>From: Farid Zaripov [mailto:[EMAIL PROTECTED]
>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
>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
RE: [PATCH] punct.cpp
>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
>
>
>
