cline@suntan.ece.clarkson.edu (Marshall Cline) (07/01/89)
In <441a30e5.8f55@fiero.engin.umich.edu>, ejd@caen (Edward Driscoll) writes: >It [[ if(x==5); ]]is legal, but I would hope for a warning from such an >obvious semantic error. In <27729@lll-winken.LLNL.GOV>, berry@lll-crg (Berry Kercheval) writes: >Goodness, save me from useless warnings for perfectly good C >constructs. This is NOT an "obvious" semantic error. Have you never >done something like this? > while(!isspace(*cp++)); /* skip to end of word */ In <65088@yale-celray.yale.UUCP> Horne-Scott@cs.yale.edu (Scott Horne) writes: >`while' constructs with null bodies are useful, but `if' constructs like the >one above are not...... How about a change-of-subject: What about a side-effect-less expression in a while loop with an empty body? Ex: main() { int x = 0; while (x < MAX); f(x++); } The `;' after the "while (<expr>)" is of course the error here. The code is definitely wrong, since it will either do nothing or hang. Perhaps we'd be taxing lint's look-ahead ability here, but seemingly "lint" could warn for this kind of thing too. Thoughts? SPECIFICALLY: A warning could be issued with "while ( <expr> ) <body> ;" whenever neither <expr> nor <body> has any side effects. (Naturally a "for(e1; e2; e3) <b>" loop would qualify as well, where the warning would appear if neither <e2>, <e3>, nor <b> had any side effects.) Another thought: the existence of a function call in <expr> or <body> should cancel the warning since the funct could longjmp() out of the loop. Marshall -- ________________________________________________________________ Marshall P. Cline ARPA: cline@sun.soe.clarkson.edu ECE Department UseNet: uunet!sun.soe.clarkson.edu!cline Clarkson University BitNet: BH0W@CLUTX Potsdam, NY 13676 AT&T: 315-268-6591
chris@mimsy.UUCP (Chris Torek) (07/01/89)
There is a fairly simple solution to the `extra semicolon' problem: use a prettyprinter. I feed much of my code through `indent' (included with recent 4BSD and SunOS releases). This has the side effect of making conflicts between layout and code structure vanish. (Some may not like this solution. Another approach, simpler than Arthur Olson's change to lint, is to have lint complain about *every* null statement unless it is prefixed by an anti-complaint comment, such as `/*skip*/' or `/*void*/' or `/*empty*/'.) -- In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163) Domain: chris@mimsy.umd.edu Path: uunet!mimsy!chris