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