From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26403 invoked by alias); 3 Feb 2003 23:41:49 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 26382 invoked by uid 48); 3 Feb 2003 23:41:49 -0000 Date: Mon, 03 Feb 2003 23:41:00 -0000 Message-ID: <20030203234149.26381.qmail@sources.redhat.com> To: axiong@ca.ibm.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, paolo@gcc.gnu.org From: paolo@gcc.gnu.org Reply-To: paolo@gcc.gnu.org, axiong@ca.ibm.com, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, paolo@gcc.gnu.org, gcc-gnats@gcc.gnu.org Subject: Re: libstdc++/9548: 64-bit copiling/linking: incorrect results from setf(ios::fixed) or precision(-1) X-SW-Source: 2003-02/txt/msg00158.txt.bz2 List-Id: Synopsis: 64-bit copiling/linking: incorrect results from setf(ios::fixed) or precision(-1) Responsible-Changed-From-To: unassigned->paolo Responsible-Changed-By: paolo Responsible-Changed-When: Mon Feb 3 23:41:49 2003 Responsible-Changed-Why: Fixing. State-Changed-From-To: open->analyzed State-Changed-By: paolo State-Changed-When: Mon Feb 3 23:41:49 2003 State-Changed-Why: According to 22.2.2.2.2 p11, if (flags & fixed) != 0 then str.precision() is specified in the conversion specification, even when str.precision is <= 0. Admittedly, this is quite a weird situation, which triggers a bug in the current library: it prepares a "%.*f" format but then calls snprintf without passing the precision field. Instead of fixing the bug, I'm going to implement the resolution of DR231, which is in the "Ready" state: according to it str.precision is simply _always_ specified in the conversion specification. Thanks for your report, Paolo. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9548