Travis Vitek wrote:
Travis Vitek wrote:
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.
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.
I've tested the patch on AIX, and it fixes failure of regression test
22.locale.num.put.stdcxx-2. Unfortunately it causes an additional 22
assertions to fail in 22.locale.num.put.
Travis
I took the time to look at this, and I think 22.locale.num.put.cpp is
wrong given the resolution of LWG231. Here are a few of the failing
assertions from 22.locale.num.put...
Here's the full set I get for num_put<char> on AIX 5.3:
$ ./22.locale.num.put --no-wchar -q --csv \
| cut -d, -f5- | sed "s/num_put<char>:://"
1729, "line 377: put (..., double = 1.1) wrote ""1"", expected ""1.1"""
1730, "line 377: put (..., double = 1.1) wrote ""1"", expected ""1.1"""
1731, "line 377: put (..., double = -1.1) wrote ""-1"", expected ""-1.1"""
1732, "line 377: put (..., double = -1.1) wrote ""-1"", expected ""-1.1"""
1817, "line 377: put (..., long double = 2.1) wrote ""2"", expected
""2.1"""
1818, "line 377: put (..., long double = -3.2) wrote ""-3"", expected
""-3.2"""
1819, "line 377: put (..., long double = -4.3) wrote ""-4"", expected
""-4.3"""
1829, "line 377: put (..., long double = 255) wrote ""3e+02"",
expected ""255"""
1830, "line 377: put (..., long double = 255) wrote ""3e+02"",
expected ""255"""
1831, "line 377: put (..., long double = 127) wrote ""1e+02"",
expected ""127"""
1832, "line 377: put (..., long double = 32767) wrote ""3e+04"",
expected ""32767"""
1833, "line 377: put (..., long double = 65535) wrote ""7e+04"",
expected ""65535"""
# +-----------------------+----------+----------+----------+
# | DIAGNOSTIC | ACTIVE | TOTAL | INACTIVE |
# +-----------------------+----------+----------+----------+
# | (S1) INFO | 49 | 49 | 0% |
# | (S2) NOTE | 2 | 2 | 0% |
# | (S5) WARNING | 1 | 1 | 0% |
# | (S7) ASSERTION | 12 | 852 | 98% |
# +-----------------------+----------+----------+----------+
Notice that the precision field value is 0 in the above cases. The
resolution for LWG231 says that for floating point types,
str.precision() is always used in the conversion specification. So each
of the above tests would need to take this into account.
Yes, although it's not immediately obvious to me what the problem
is, The first assertion above corresponds to this line:
TEST (T, 1.1, 0, 0, 0, ' ', "", "%g");
I don't see where the test ends up formatting 1.1 as 1.1 using the
"%g" directive (on AIX, printf("%g", 1.1) produces 1 as expected.
Martin
We are currently consistent with several other implementations. I don't
believe that either of them implement the LWG231 resolution. The GNU
implementation does implement the new behavior.
Travis
