limes@sun.com (Greg Limes) (07/13/89)
In article <105@borabora.omni.com> bob@omni.com (Bob Weissman) writes:
Last week I spent an entire day tracking down one of those bugs you just
don't see after staring at your code too long. It was of the form:
if (condition);
action;
You mean this never bit you before? Put it in your list of common
things to look for when the bugs get weird, along with confusing the
assignment and equality test operations. watch even for the
combinations; I kid you not, I once saw this:
if (fp = (struct file *)0);
perror("opening file");
Yes, C is sometimes difficult to debug.
Oh, you want an easy way to find those extra semicolons, and
mismatched comment delimiters? Run the code through "indent", or
something like it. If the indentation does not match what you think
the code should be doing, look again carefully ...
--
Greg Limes limes@sun.com ...!sun!limes 73327,2473 [chose one]fnf@estinc.UUCP (Fred Fish) (07/15/89)
In article <LIMES.89Jul12153110@ouroborous.wseng.sun.com> limes@sun.com (Greg Limes) writes: > >In article <105@borabora.omni.com> bob@omni.com (Bob Weissman) writes: > Last week I spent an entire day tracking down one of those bugs you just > don't see after staring at your code too long. It was of the form: > > if (condition); > action; > >You mean this never bit you before? Put it in your list of common >things to look for when the bugs get weird, along with confusing the I can honestly say that I have NEVER been bitten by this sort of bug in my own C code, because my style rules dictate that it be written as: if (condition) { action; } and it would never occur to my fingers to stick a ';' in place of the '{'. Just because the {} are optional is no reason to leave them out. If you are going to leave them out, at least have the decency to write it as: if (condition) action; (Sorry about the obvious, but this is my pet peeve #1 about other people's code...) -Fred -- # Fred Fish, 1835 E. Belmont Drive, Tempe, AZ 85284, USA # 1-602-491-0048 asuvax!{nud,mcdphx}!estinc!fnf
bob@omni.com (Bob Weissman) (07/16/89)
In article <203@estinc.UUCP>, fnf@estinc.UUCP (Fred Fish) writes: > I can honestly say that I have NEVER been bitten by this sort of bug in > my own C code, because my style rules dictate that it be written as: > if (condition) { > action; > } ... > If you are going to leave them out, at least have the decency to > write it as: > if (condition) action; > (Sorry about the obvious, but this is my pet peeve #1 about other > people's code...) P L E A S E, let us not begin another round of My C Coding Style Is Better Than Yours. How boring. Remember the origin of this thread of discussion was lint. I still maintain that lint ought to warn you about "if (e);". -- Bob Weissman Domainish: bob@omni.com UUCPish: ...!{amdahl,apple,pyramid,tekbspa,uunet}!koosh!bob
ari@eleazar.dartmouth.edu (Ari Halberstadt) (07/17/89)
This is my first submission to this group. I hope I reply correctly.
For the past week or so, there's been this discussion about null statements
inserted by mistake after an if. It was suggested that lint be modified to
catch these errors. I would support this, but only as an extra option to
lint, not a default action, since I frequently use while and for loops with
null statements.
For myself, I rarely run into this bug. I simply type carefully, and
realize that such bugs usually creep in at 2AM.
An execellent book on the topic of bugs and pitfalls is:
-- Andrew Koenig, "C Traps and Pit Falls", Addison-Wesley, Reading,
Massachusetts (1989).
About the suggestion to type:
if (expr) {
stmt;
}
I really DON'T like seeing this kind of use of parenthesis in code. But if
it works for some people, let them use it.
-- Ari Halberstadt
Ari Halberstadt: ari@dartmouth.edu