Path: utzoo!utgpu!jarvis.csri.toronto.edu!rutgers!mailrus!ncar!ico!ism780c!haddock!karl From: karl@haddock.ima.isc.com (Karl Heuer) Newsgroups: comp.lang.c Subject: Re: lint won't verify printf formatting against variable types?? Keywords: lint, cc Message-ID: <13889@haddock.ima.isc.com> Date: 29 Jun 89 21:09:21 GMT References: <328@tree.UUCP> <417@siswat.UUCP> <27729@lll-winken.LLNL.GOV> <115@borabora.omni.com> Reply-To: karl@haddock.ima.isc.com (Karl Heuer) Organization: Interactive Systems, Boston Lines: 28 In article <115@borabora.omni.com> bob@omni.com (Bob Weissman) writes: >I'm talking about > if (expression); >which, while legal, *never* makes sense semantically Well, some versions of || do this deliberately. (But these should be fixed anyway, since the pANS requires |assert()| to be a void-valued expression macro, and it's not hard to do this.) And I have, myself, used a null-bodied |if| with an |else| clause, in situations where this was clearer than a straight |if| with the condition inverted. It would be within the "spirit of lint" to warn about *all* null statements, provided (a) any instance can be silenced with the lintpragma |/*NULL*/|, and (b) the warning can be disabled by a command-line option. (Probably |if| and |while| should have separate flags, since many people depend on null-bodied |while|.) Why warn about null |while| at all? Because it's *possible* that it's a typo, just as with |if|; and those of use who never write it that way would be able to make good use of the warning. (Some of us always use |/*NULL*/|, or use empty braces instead of a semicolon, or write |do; while (ex);| whenever the entire loop is contained in the test.) Karl W. Z. Heuer (ima!haddock!karl or karl@haddock.isc.com), The Walking Lint ________ Note: I'll be out of town July 2-22, so I probably won't be able to reply to any followups. If you send me mail, include enough context that I'll still remember the thread three weeks later.