This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: statically linked gcc executables


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]