statically linked gcc executables
John Carter
john.carter@tait.co.nz
Tue Jan 29 13:14:00 GMT 2008
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@tait.co.nz
New Zealand
More information about the Gcc-help
mailing list