On Thu, 24 Jan 2008, Ted Byers wrote:
You're half right. If your program uses library X, and that library has a subtle bug in the function you're using, then the result you get using a different library will be different. The fix is not to ensure that you use the same library all the time, but to ensure your test suite is sufficiently well developed that you can detect such a bug, and use a different function (even if you have to write it yourself) that routinely gives you provably correct answers.
Alas, Reality bites, we all suck, nobody on planet with a non-trivial product has perfect test coverage of code and state, and we all have bugs. And even if you have really really good coverage, you seldom have the time to rerun _every_ test after every change. So given how much reality sucks, one of eminently practical things you can do is reduce the variance between what you have tested and what you ship. Test what like you fly, fly what you test. And that applies to shipping products to customers, it applies to internal products like shipping cross compilers to colleagues. As I said, Reality truly sucks. Hint: C/C++ based reality sucks even more since, unless you test heavily under Valgrind, most code has subtle uninitialized data bugs that often don't fire under even the heaviest testing. One of the reasons I like dynamic languages like Ruby. John Carter Phone : (64)(3) 358 6639 Tait Electronics Fax : (64)(3) 359 4632 PO Box 1645 Christchurch Email : john.carter@xxxxxxxxxx New Zealand
