From: Douglas A. Gwyn <gwyn@ix.netcom.com>
Newsgroups: comp.lang.c
Subject: Re: flame: _Writing Solid Code_
Date: Tue, 10 Mar 1998 07:50:05 GMT

In article <f11N.68$8J.372516@ptah.visi.com>,
	seebs@plethora.net (Peter Seebach) wrote:

>I once spent nearly a week trying to debug a memory leak.  ...
>I found it in fifteen minutes; it was just a question of sitting down and
>*reading* the damn thing.

A debugger can help find a clue when you really are stuck with
a run-time problem.  The best debuggers don't disturb the envrionment
in which the debugged process runs, unlike inserting tracing code or
recompiling with NDEBUG undefined.

That said, I agree that most C programming errors can be better
detected by code review, if conducted with the proper attitude
(where one continually challenges all assumptions).  The errors
that don't tend to be caught that way are often problems with the
algorithm, and sometimes the clues from a debugger intelligently
applied can help discover what is going wrong.

There is one class of problem that practically *requires* use of
a debugger, and that is when the implementation is faulty (e.g.
bad code generation).  For example, I once encountered a system
that underallocated the stack frame by one word, which happened
not to matter unless an interrupt (signal) occurred..  Very hard
to figure out without coding up a small test case and examining
in detail every step of its operation (again, challenging every
assumption, including that the compiler knew what it was doing).