[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Subtle conversion bug in strtod (hence atof)

From: 1-914-784-7648
Subject: Subtle conversion bug in strtod (hence atof)
Date: Tue, 07 Nov 2006 14:34:08 -0000

The basic idea of limiting the number of decimal digits that need to
participate in conversion arithmetic is a good one, btw; it's just that
the limit picked by strtod() is too small and does not take the exponent
into account.

As many digits as it takes to represent a binary halfway point exactly
must be processed.  The worst case is 752 digits for double, for numbers
near Nmin/2.  If the binary exponent is known at this point (I think it
is, based on quick code browsing), the max can be computed.  I enclose
the comments from my own conversion program:

*     When the normalised binary exponent B exceeds the frac-
*     tion length F (in bits), the length of an exact decimal
*     represention is .3 B digits, otherwise (e.g. negative B)
*     it is (F + .7 B) digits (or (F-B) + .3 B).  We need to
*     detect exact half-way points, so we need to consider F+1
*     instead of the F derived from the format.

(Here .3 and .7 are short for log10(2) and log10(5) of course.)

Sent: 2006-11-07 14:33:38 UTC

reply via email to

[Prev in Thread] Current Thread [Next in Thread]