This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/9548: 64-bit copiling/linking: incorrect results from setf(ios::fixed) or precision(-1)
- From: paolo at gcc dot gnu dot org
- To: axiong at ca dot ibm dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, paolo at gcc dot gnu dot org
- Date: 3 Feb 2003 23:41:49 -0000
- Subject: Re: libstdc++/9548: 64-bit copiling/linking: incorrect results from setf(ios::fixed) or precision(-1)
- Reply-to: paolo at gcc dot gnu dot org, axiong at ca dot ibm dot com, gcc-bugs at gcc dot gnu dot org, gcc-prs at gcc dot gnu dot org, nobody at gcc dot gnu dot org, paolo at gcc dot gnu dot org, gcc-gnats at gcc dot gnu dot org
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