LINT won't do your debugging for you

[Tim Meighan]

In article <411 at isadora.ikp.liu.se> hacker at isadora.ikp.liu.se
(Goran Larsson [Hacker of Hackefors]) writes:
> In article <105 at borabora.omni.com> bob at omni.com (Bob Weissman) writes:
>
>*	if (condition);
>*	    action;
>*
>* My lint (SunOS 4.0.1 version) did not flag the extra semicolon.
>
> It isn't supposed to find this "error" as it is legal C.

Yes, it is perfectly legal in C to have a null instruction block anywhere.
But we're not talking about checking for strictly legal syntax here (which
the compiler takes care of anyway), we're talking about the basic purpose
of LINT, and putting your faith in having it catch EVERYTHING.

The example raises a couple of marginally interesting points:

1. There is rarely, if ever, a case when it would be reasonable for a
   program to contain an if() statement that, when evaluated as true,
   does absolutely nothing.  (In other words, simply fall through to
   the code to be executed when the if() is false.)

2. Even assuming a use for such code, LINT should still call attention to all
   cases of null instruction blocks on GP, since they probably represent a
   mistake rather than intentional coding.

Therefore, a case can be made that there was a "failure" on the part of
the LINT program.  So is it right to blame LINT (or C) for this?
   
Of course not.  Tools like LINT are good to get a fresh perspective on
what you already need to know; they will always fail if you expect them to
think for you.  I sympathize with Mr. Weissman -- I've been through the same
maddening and humbling experience more times than I care to admit.  I CAN say
that such experiences have made me a better problem-solver, so I consider
the time well spent.

I certainly wouldn't blame C (or LINT) for my mistakes.

Tim Meighan
SilentRadio

"I've got one, two, three, four, five . . . senses working overtime!"