Travis Vitek wrote:
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.
I suspect we followed the original proposed resolution in our
implementation:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1350.html#231
We should have deferred implementation of the resolution until
the LWG approved it...
Martin
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
