bright@Data-IO.COM (Walter Bright) (01/19/88)
In article <434@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes: > a = b/*c; >My friend spent two days looking for that one... You said that the compiler gave an 'unexpected EOF' error message. I'm surprised that more people don't use the binary search method of finding errors. In the above case, you copy your source file to test.c. Delete the bottom half of it. Recompile. If you get the error again, delete the bottom half of the remainder, etc., else copy the backup file to test.c and delete the bottom quarter, etc. You can easily see that the bug will be rapidly isolated. The binary search method is extremely useful when the compiler won't tell you what error the line was on, or if it crashes while compiling. I use this technique a lot when debugging my compiler :-). A more subtle bug I've had serious problems with is: a = b; /* some explanatory comment c = d; /* another comment */ Note the missing */ on the first comment, causing the c = d; to be ignored, which was very difficult and frustrating to find. Wasting my time on this is the primary reason why my compiler generates a warning if a /* is encountered within a comment, this stops the bug cold.
mds7958@ritcv.UUCP (Mark Sicignano) (01/19/88)
> In article <434@drilex.UUCP> dricej@drilex.UUCP (Craig Jackson) writes: > > a = b/*c; > >My friend spent two days looking for that one... > > A more subtle bug I've had serious problems with is: > > a = b; /* some explanatory comment > c = d; /* another comment */ > > Note the missing */ on the first comment, causing the c = d; to be ignored, > which was very difficult and frustrating to find. Wasting my time on this I use the following little script. It will display your C source files with the code being boldface and the comments being normal intensity. If you have a /* or a */ that doesn't belong, you will be able to see it right away. This will work on VT100 or any terminal which recognizes the ANSI escape sequences I used. Note that the ^[ is really an escape ( 0x1b in hex). ---cut here---------------------------------------------------- echo '^[[1m' expand $* | sed '{ s/\/\*/^[[0m\/\*/g s/\*\//\*\/^[[1m/g }' ---cut here----------------------------------------------------
jackm@devvax.JPL.NASA.GOV (Jack Morrison) (01/19/88)
[anguish over bugs like: ] >> > a = b/*c; >> >> a = b; /* some explanatory comment >> c = d; /* another comment */ >> 1. These fall in the class of "=" vs. "=="; anyone can write a program to check for all these stupid mistakes we make all the time (yes, even I have one; ask by mail if you want it). I think we've seen enough, yes? 2. "Binary search" for mysterious problems is good as a last resort, but one recommendation (stolen from Robert Ward's helpful book _Debugging C_): rather than deleting code and juggling multiple copies, use #ifdef JUNK ... #endif JUNK to remove the next half from consideration. -- Jack C. Morrison Jet Propulsion Laboratory (818)354-1463 jackm@jpl-devvax.jpl.nasa.gov "The paycheck is part government property, but the opinions are all mine."