homepage

> 	if (!(dig = quorem(b,d))) {
> 		b = multadd(b, 10, 0);	/* very unlikely */
> 		dig = quorem(b,d);
> 		}
> 
> This code is part of the algorithm for strtod. Here b and d are
> Bigints, and b / d is a fraction that gives an approximation to 
> the value of the input to strtod; the aim is to produce the 
> digits of b / d one-by-one to compare them with the strtod input,
> and (eventually) use the result of that comparison work out whether
> to round up or down.
> If the condition of the 'if' block above is ever satisfied, b is 
> multiplied by 10 (that's the multadd(b, 10, 0) call), so the 
> fraction b / d is multiplied by 10 (with no corresponding correction
> for the strtod input string), and the wrong comparison is made!
Mark,
I think I know the motivation for this code, although I still don't know how it could hit. The halfway value H is scaled by a power of ten to put it in the form "d1.d2d3d4d5...". The power of ten exponent is derived from the input decimal string S, instead of computing it from H using logarithms.
Now what if H's exponent does not match S's? I'm thinking of cases like S = 10^n and H = 9.99999999... * 10^(n-1). Scaling H by 10^-n would make it 0.999999999... . That leading 0 needs to be removed, by multiplying by 10, do put it in the right form.
First of all, I don't know if a case like this is possible. Second of all, the check would fail either way (1 against 0 vs 1 against 9).
 
BTW, b / d represents only the significant digits of H, so it shouldn't matter that there's no corresponding adjustment to the input string.
To summarize: I'm not saying this code is necessary; I'm just saying it makes you wonder.