This is the mail archive of the
newlib@sourceware.org
mailing list for the newlib project.
Re: RFC/RFA: strtod() magnitude problem
- From: Corinna Vinschen <vinschen at redhat dot com>
- To: newlib at sourceware dot org
- Date: Wed, 24 Apr 2013 12:21:40 +0200
- Subject: Re: RFC/RFA: strtod() magnitude problem
- References: <87vc7d3a4g dot fsf at redhat dot com> <20130423120946 dot GB26397 at calimero dot vinschen dot de> <5176B4FB dot 8060308 at redhat dot com> <20130423164731 dot GB20963 at calimero dot vinschen dot de> <517796F4 dot 1000800 at redhat dot com>
- Reply-to: newlib at sourceware dot org
On Apr 24 09:25, nick clifton wrote:
> Hi Corinna,
>
> >>One point - this part of your patch:
> >>
> >>> static _CONST double tinytens[] = { 1e-16, 1e-32, 1e-64, 1e-128,
> >>>- 9007199254740992.e-256
> >>>+ 9007199254740992.*9007199254740992.e-256
> >>> };
> >>
> >>appears to be a typo. I have removed it in my revised patch, but
> >>maybe it needs fixing ?
> >
> >I'm not sure. I copied this from the NetBSD code verbatim:
> >
> >/* The factor of 2^106 in tinytens[4] helps us avoid setting the underflow */
> >/* flag unnecessarily. It leads to a song and dance at the end of strtod. */
> >static CONST double tinytens[] = { 1e-16, 1e-32, 1e-64, 1e-128,
> > 9007199254740992.*9007199254740992.e-256
> > };
> >
> >Note that not only the value itself is changed, the 2^53 in our version
> >of the comment is replaced by a 2^106. I just checked against OpenBSD,
> >and their code contains the exact same change.
> >
> >So I think it was right. Sure, even two upstream can be wrong, but still...
>
> Ok - but please can we at least have a couple of spaces around the
> asterisk so that the it is more obvious that we are multiplying
> together two constants rather than trying to construct some kind of
> bizarre mega number. Ie:
>
> 9007199254740992. * 9007199254740992.e-256
>
> Also - the last three entries in the tinytens[] array evaluate to 0
> for a _DOUBLE_IS_32BITS target, and they produce a compile time
> warning message about that. So I have attached a revised patch
> which explicitly stores 0.0 in these entries. Is this version OK ?
Yep. Applied with this change.
Thanks,
Corinna
--
Corinna Vinschen
Cygwin Maintainer
Red Hat