This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
Re: how to make code stay invariant
On Tue, 25 Jul 2006, Rolf Schumacher wrote:
John, we're living in a real world. I can tell:
you can't say: retest 100000 lines of code
upon a small change. Believe me.
That's why you do Test Driven Development with a test harness to run all
automated tests.
It really really does work in very real world environments with even
larger code bases. It really really does improve design. You really can
rerun all tests on 100000 lines of code.
If you can't rerun all tests, it is quite simply because you designed it
wrong. You didn't design it for testability.
And in a safety critical App that is gravely remiss.
Places to start reading are...
http://www.objectmentor.com/resources/bookstore/books/welc/
http://www.agiledata.org/essays/tdd.html
We have to come up with some better idea.
TDD _is_ the better idea.
For now I'd like to focus solely on dynamic errors.
Errors to happen while compiling, linking, loading and running.
You know something, I have been bitten by some compiler bugs in my time.
Pretty rare, but they happen.
I would estimate looking at my current project (200000+ LOC, a man
decade or two of development, real time embedded C) that we have about 3
full orders of magnitude more programmer bugs than compiler bugs. None
of them were sporadic. A correct program simply failed to compile.
We have never been bitten by linker bugs at all. Well, admittedly
writing gnu ld script is actively user hostile, but it either worked or
it didn't.
We have had lots of loader bugs, but then for various strange reasons,
we wrote our own. In all my years programming I have never been bitten
by an OS loader bug. There is a moral there...
An error I'd like to uncover is: I'm linking on a PC/XP
and somehow a bit changes just before the linker
packs the object to be written to the disk. Checksum is ok,
the object is bad.
Wow! That is such a low probability risk compare to Good Old Human stuff
ups, I wouldn't even give it a moments thought unless I had actually
seen it happening once.
If you really having such errors you have a buggy linker, time for a
newer (or older) version fast, or you have buggy hardware. ie. Fix the
tool, don't create a kludgy workaround patch around the broken tool.
If I had a checksum from last linking and made no change
I could point to the failure immediately, e.g. at load time.
Some (targets/versions) of the GCC linker do relaxation passes. ie.
Change long jumps to short jumps, change long references to short
offsets. And since the size of the code has shrunk, they do that again,
and again until it converges.
Basically you want each module to be a DLL/sharable object so the linker
does the absolute minimum of fix ups.
You also need a strict acyclic dependency graph between the sharable
objects and then link each layer with lower layers.
Follow the standard tricks to make a sharable object / DLL.
You still need the objdump tricks I mentioned to pull just the sections
you care about out.
The point that I'm asking is,
Somehow your mailer lost everything you wrote after this point in your post!
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
Carter's Clarification of Murphy's Law.
"Things only ever go right so that they may go more spectacularly wrong later."
From this principle, all of life and physics may be deduced.