Re: RFC/RFA: strtod() magnitude problem

[Corinna Vinschen <vinschen at redhat dot com>]

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