From dev-return-6997-apmail-stdcxx-dev-archive=stdcxx.apache.org@stdcxx.apache.org Wed Mar 05 19:52:54 2008 Return-Path: Delivered-To: apmail-stdcxx-dev-archive@www.apache.org Received: (qmail 56312 invoked from network); 5 Mar 2008 19:52:54 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 5 Mar 2008 19:52:54 -0000 Received: (qmail 54322 invoked by uid 500); 5 Mar 2008 19:52:50 -0000 Delivered-To: apmail-stdcxx-dev-archive@stdcxx.apache.org Received: (qmail 54313 invoked by uid 500); 5 Mar 2008 19:52:50 -0000 Mailing-List: contact dev-help@stdcxx.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stdcxx.apache.org Delivered-To: mailing list dev@stdcxx.apache.org Received: (qmail 54304 invoked by uid 99); 5 Mar 2008 19:52:50 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Mar 2008 11:52:50 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [208.30.140.160] (HELO moroha.roguewave.com) (208.30.140.160) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 05 Mar 2008 19:52:04 +0000 Received: from exchmail01.Blue.Roguewave.Com (exchmail01.blue.roguewave.com [10.22.129.22]) by moroha.roguewave.com (8.13.6/8.13.6) with ESMTP id m25JqNU0006007 for ; Wed, 5 Mar 2008 19:52:23 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Subject: RE: [PATCH] punct.cpp Date: Wed, 5 Mar 2008 12:52:20 -0700 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] punct.cpp Thread-Index: Ach5Wm/9SYI3Dj3cR0uMx7QM3NmhdwACXvsgAAOlD7UABNY2IAFaND0gAAGWlCA= References: <7BDB2168BEAEF14C98F1901FD2DE643801B84211@epmsa009.minsk.epam.com> From: "Travis Vitek" To: X-Virus-Checked: Checked by ClamAV on apache.org =20 >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... // +-- value to format // | +-- fmtflags // | | +-- precision // | | | +-- field width // | | | | +-- fill character // | | | | | +-- grouping // | | | | | | +-- expected output // | | | | | | | // V V V V V V V TEST (T, 1.1, 0, 0, 0, ' ', "", "%g"); TEST (T, 1.1, 0, 0, 0, ' ', "", "1.1"); TEST (T, -1.1, 0, 0, 0, ' ', "", "%g"); TEST (T, -1.1, 0, 0, 0, ' ', "", "-1.1"); TEST (T, 0.0L, 0, 0, 0, ' ', "", "%Lg"); TEST (T, 1.0L, 0, 0, 0, ' ', "", "%Lg"); TEST (T, 2.1L, 0, 0, 0, ' ', "", "%Lg"); TEST (T, -3.2L, 0, 0, 0, ' ', "", "%Lg"); TEST (T, -4.3L, 0, 0, 0, ' ', "", "%Lg"); // there are more... 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. 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