Floating-point to decimal conversion is a little bit trickier than usually thought (cf. Steele&White, "How to Print Floating-Point Numbers Accurately", SIGPLAN

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?)