stdcxx-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor" <>
Subject RE: [PATCH] punct.cpp
Date Wed, 27 Feb 2008 19:08:24 GMT
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:


-----Original Message-----
From: Travis Vitek []
Sent: Wed 2/27/2008 10:54 AM
Subject: RE: [PATCH] punct.cpp

>From: Farid Zaripov [] 
>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 
>is not used in sprintf() format string generated by
>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:
> 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) {
>             //, p5 of C99 specifies that, when given 
>using the
>             // asterisk, negative precision is treated the same as if

I haven't tested your patch, but it looks like it is consistent with the
resolution of WG231.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message