🚀 go-pugleaf

     Do you have a trick or two for polishing and/or debugging "C"
code using typical Unix(tm) tools?  I am interested in anything that
helps locate coding errors, particularly those techniques that use
programs available on run-of-the-mill Unix-based systems.
     I am making a collection and will post it to the net.  Please mail
your submissions instead of posting them to this group.

     Here is an example of what I'm looking for;

     I use cb(1) and diff(1) to catch what I'll call grouping or indentation
problems.  I fall into this trap when my first version of code has a single
statement inside an if-statement's true clause and then I later go back and
add another line or two of code.

fragment()
{
	if (moveit(datap, dev) == 0)
		assert(dvcp->c_res == 0);                   <----- ADDED LINE
		if (dvcp->c_flags & ASYNC) {
			status = q_send(dvcp->c_id, &end);
			assert((status == E_NOERR) || (status == E_OBJDEL));
		}
}

     Both versions will compile and lint(1) (in the full version, not the
fragment I've shown above) without detecting the error.  Visually, the
second if-statement version is within the first if-statement's true clause.
However, the compiler ignores indentation and generates the second
if-statement code completely outside of the first.
     I recently spent two days tracking down one of these errors!

"Fool me once, shame on you [the compiler].  Fool me twice, shame on me!"

     Using cb(1) and diff(1), I developed a quick check that will find
this type of error.

     Briefly, the source file is "beautified" and compared to the original.
Any differences, such as in the amount of indentation I think is necessary
versus what cb(1) thinks is needed are pointed out by diff(1).

          cb $f | diff - $f

     One drawback, of course, is that the source file must be coded in
a cb(1) format in order to use cb(1) to "find" differences between what
I mean and what the compiler will understand.  This format may not conform
with your favorite style, nor that of your employer.  However, I am willing
to change my habits (and style) when I find something that will help me
generate better code in less time.

-- 
"Wisdom is the absence of ideals."  Chinese proverb
#include <disclaimer.h>
Ed Skinner, Technical Training, Motorola Inc., MicroComputer Division
2900 S Diablo Way, Tempe Az 85282, USA (602)438-3956
Internet: edski@phx.mcd.mot.com,  UUCPnet: noao!asuvax!mcdphx!edski