tcm@srhqla.SR.COM (Tim Meighan) (06/29/89)
In article <411@isadora.ikp.liu.se> hacker@isadora.ikp.liu.se (Goran Larsson [Hacker of Hackefors]) writes: > In article <105@borabora.omni.com> bob@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!"
usenet@cps3xx.UUCP (Usenet file owner) (06/29/89)
in article <713@srhqla.SR.COM>, tcm@srhqla.SR.COM (Tim Meighan) says: > > 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.) When implementing some very low level code in C under MSDOS, an if with a null body provides a very handy slight delay. Example: after sending the address to the CMOS RAM on an AT, you need a slight pause on a fast machine to then read or write its contents. Unfortunately, alot of compilers optimize it out. John H. Lawitzke UUCP: Work: ...uunet!frith!dale1!jhl Dale Computer Corp., R&D Home ...uunet!frith!ipecac!jhl 2367 Science Parkway Internet: jhl@frith.egr.msu.edu Okemos, MI, 48864 [35.8.8.108]
friedl@vsi.COM (Stephen J. Friedl) (06/30/89)
> if (condition); <--- note semicolon > action; In article <713@srhqla.SR.COM>, tcm@srhqla.SR.COM (Tim Meighan) writes: > > 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.) Some versions of lint will in fact warn about empty blocks, and for those few times when this is really what you want, the /*EMPTY*/ lintpragma suppresses this warning. Steve -- Stephen J. Friedl / V-Systems, Inc. / Santa Ana, CA / +1 714 545 6442 3B2-kind-of-guy / friedl@vsi.com / {attmail, uunet, etc}!vsi!friedl ---> vsi!bang!friedl <-- NEW "Friends don't let friends run Xenix" - me
gwyn@smoke.BRL.MIL (Doug Gwyn) (07/01/89)
In article <713@srhqla.SR.COM> tcm@srhqla.UUCP (Tim Meighan) writes:
!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.
How about macro expansions or code generated by another program?
A similar case (null "false" branch) is often seen:
#define swap(a,b,type) if(1){type t=(a);(a)=(b);(b)=t;}else
!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.
It should probably be an option, so one could disable the reams of
warnings that extensive deliberate use of such code could generate.