[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.)
Michel.
Sent: 2006-11-07 14:33:38 UTC