This is the mail archive of the
mailing list for the newlib project.
Re: Bug in Cygwin strtod()
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Date: Wed, 9 Jan 2013 19:02:33 +0100
- Subject: Re: Bug in Cygwin strtod()
- References: <1355878473.91036.YahooMailNeo@web121001.mail.ne1.yahoo.com> <50D118CE.email@example.com> <50D166D2.firstname.lastname@example.org> <20121219101618.GA13560@calimero.vinschen.de> <50D1A880.email@example.com> <20121219125804.GA4120@calimero.vinschen.de> <50EAA2F9.firstname.lastname@example.org>
- Reply-to: newlib at sourceware dot org
On Jan 7 11:27, Christian Bruel wrote:
> Here is a less intrusive patch to fix the earlier issues on small
> DBL_DIG targets. I added a testsuite file to track the values that
> caused errors. Including original SH4 -m4-single-only failures and the
> recent regression with the M_LN10 rounding.
> The rounding code seems to assume that DBL_DIG is bigger than 9 when
> reading the dval value. So I fixed the setting of dval so at the 9
> digits are read (if less digits than 9 this is fine). This fixes the
> problem, even if it's still possible that a fix in the rounding code
> exists, but there are so many configuration settings that this looks
> quite fragile to touch.
I have a hard time to see that this is the right way to fix this
problem. It doesn't seem to make sense from the context.
The question is, why does the original code assume that DBL_DIG is
bigger than 9? There are a few places where tests for 9 or 10 are
performed, without any explanation of the reason. Incidentally, this
doesn't make it easier to understand the code at all.
Anyway, assuming we understand the code, the right thing to do would be
to change the arbitrary looking fixed tests for 9 and 10 to a more
dynamic way which depends on DBL_DIG, as far as I can see.
Idle musing: It would be nice if somebody would take a heart and
start adding comments for better understanding...
Cygwin Project Co-Leader