

Explaining the Excel Bug - lackbeard
http://www.joelonsoftware.com/items/2007/09/26b.html

======
shiro
Floating-point to decimal conversion is a little bit trickier than usually
thought (cf. Steele&White, "How to Print Floating-Point Numbers Accurately",
SIGPLAN '90, pp.112-126, 1990. and also Burger&Dybvig, "Printing Floating-
Point Numbers Quickly and Accurately", PLDI '96, pp.108--116, 1996.), and
tweaking the algorithm can easily introduce special cases in the code path.

Now I don't have any idea why Excel had such special cases around 65535, but
this incident seems to confirm my growing suspicion that it is wrong not to
test 100% of code paths. Some of you may say off course it is, but I've seen
programmers that just test a few sample points and then bombarding the code
with random input and say it's working. I myself have been bitten by some bugs
hidden in rare code paths since I was lazy to construct a special input that
tests the path, which sometimes takes some effort. (I haven't used automated
test case generation tools; any opinions?)

------
dfranke
Joel is letting them off easy when he talks about how it's unlikely that this
bug would come out in testing. He's right that black-box tests wouldn't catch
it. But, obviously someone wrote some special-case logic for formatting 65535
and 65536, and there's absolutely no reason that that special case logic
should be there. That code should have been flagged during code review and
terminated with extreme prejudice.

