Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!uunet!seismo!mcnc!ece-csc!ncrcae!ncr-sd!hp-sdd!hplabs!sdcrdcf!trwrb!cadovax!gryphon!greg
From: greg@gryphon.CTS.COM (Greg Laskin)
Newsgroups: comp.sys.ibm.pc
Subject: Re: Turbo C/Pascal, debugging
Message-ID: <929@gryphon.CTS.COM>
Date: Thu, 9-Jul-87 22:46:48 EDT
Article-I.D.: gryphon.929
Posted: Thu Jul  9 22:46:48 1987
Date-Received: Sun, 12-Jul-87 11:04:03 EDT
References: <719@imsvax.UUCP>
Reply-To: greg@gryphon.CTS.COM (Greg Laskin)
Organization: Trailing Edge Technology, Redondo Beach, CA
Lines: 63

In article <719@imsvax.UUCP> Ted Holden writes:

>     I regard most of the debugging systems in the mini-micro world as
>jokes.  For simply seeing variable values at specific points in a
>program, printf's and writeln's are faster, given something really fast like
>Borland's systems.  Further, the notion of single-stepping through
>real-world programs strikes me as ludicrous.  In real life, problems
>often show up in the middle of some 700 line loop on the 300'th pass
>through.  Only a masochist would want to single-step through that.

This is a matter of taste and experience.  In real life, most of the
bugs in C programs that I've been called upon to fix involve
unintented and sometimes very transitory side effects of errant
code.  Frequently, the code causing the damage is quite distant
from the point of impact.  In many cases adding print statements to 
an ailing program has been known to change
the memory layout sufficiently to move or totally mask the problem.
I've  never (in 20 years) seen a 700 line loop or a problem that 
needed 300 passes through a loop to show up, although I'm sure
that both situations are possible.  

Being able to use Codeview may not be an advantage of MSC however
NOT being able to use Codeview is also NOT an advantage of Turbo C
over MSC.

In general, it is sometimes necessary to bang around in the
assembly level code generated by the compiler.  Codeview is
nice at those times.  Other debuggers (SYMDEB, DEBUG and adb)
are just about as useful but the Codeview user interface is
"nicer".
>
>     The idea of a hardware debugger, such as Periscope's, is valid;  if
>you need to see values of variables AFTER the system crashes, there
>ain't no other way.

There are other elements of the art of debugging beyond seeing the
contents of variables.  It's useful to know EXACTLY what your program
is doing as opposed to what you THINK it's doing.  Single stepping
(more precisely breakpointing) helps you to see EXACTLY what your
program is doing in large part because it forces you to examine
the structure and flow of your program.  Many of the "difficult"
bugs are those where you meant to write something other than what you
actually wrote.  There's a strong tendency to read past these
when you look at what you wrote, because you read what you MEANT
instead of what you WROTE.  Single stepping makes this kind of
bug show up rather quickly because it forces you to look at
something other that what you wrote.

>This [array bounds checking] is tremendously useful, and I don't see it in
>Turbo C or hear about it from Microsoft, although I have to believe that
>Borland will have this kind of feature in Turbo C long before MicroSoft
>hears about it. 

C doesn't do array bounds checking.  If Turbo C were to do array
bounds checking, it wouldn't be C.


-- 
Greg Laskin   
"When everybody's talking and nobody's listening, how can we decide?"
INTERNET:     greg@gryphon.CTS.COM
UUCP:         {hplabs!hp-sdd, sdcsvax, ihnp4}!crash!gryphon!greg
UUCP:         {philabs, scgvaxd}!cadovax!gryphon!greg