RFC/RFA: strtod() magnitude problem

[Corinna Vinschen]

On Apr 23 17:21, nick clifton wrote:
> Hi Corinna,
> 
> >Can you try if the below patch fixes the issue?  It's just a manual
> >update of strtod (or rather _strtod_r) to the latest implementation
> >from NetBSD.  There were a few changes which might explain your problem
> >as well as the one encountered by Christian Bruel.
> 
> It does - although I had to tweak it slightly.  (Tweaked version
> attached).  There was one place I found where the dword1() macro was
> being used unsafely.  The attached patch includes a fix for this.
> There are other places where dword1() is used without checking
> DOUBLE_IS_32BITS, but these places are safe.

Thanks!

> 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...


What do you think?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat