Path: utzoo!attcan!lsuc!eci386!jmm From: jmm@eci386.uucp (John Macdonald) Newsgroups: comp.lang.c Subject: Re: lint won't verify printf formatting against variable types?? Keywords: lint, cc Message-ID: <1989Jun30.180909.21548@eci386.uucp> Date: 30 Jun 89 18:09:09 GMT References: <328@tree.UUCP> <417@siswat.UUCP> <441a30e5.8f55@fiero.engin.umich.edu> <27729@lll-winken.LLNL.GOV> <2271@trantor.harris-atd.com> Reply-To: jmm@eci386.UUCP (John Macdonald) Organization: R. H. Lathwell Associates: Elegant Communications, Inc. Lines: 66 In article <2271@trantor.harris-atd.com> bbadger@x102c.harris-atd.com (Badger BA 64810) writes: >In article <27729@lll-winken.LLNL.GOV> berry@lll-crg.llnl.gov (Berry Kercheval) writes: >>In article <441a30e5.8f55@fiero.engin.umich.edu>, ejd@caen (Edward J Driscoll) writes: >>>It [[ if(x==5); ]]is legal, but I would hope for a warning from such an >>> obvious semantic error. >> >>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? >> >> /* skip to end of word */ >> while(!isspace(*cp++)); >> >However, > if(x==5); >most certainly is useless, in fact, > if(<>); >is *completely* equivalent to > <>; >semantically. This isn't true for ``while(<>);'', in general. >Since this is an obvious abuse of syntax, I would *hope* -- >but not necessarily *expect* -- that lint would catch such an error. If you look at pre-processor expanded source, then it is certainly *NOT* useless. I have often used code like the following... : : #ifdef DEBUG_ARGS # define SHOW_ARG(i) printf( "i is %d\n", (i) ) #else # define SHOW_ARG(i) #endif : : if( arg_flag ) SHOW_ARG( arg ); : : which pre-processes into "if();" except in the unusual case where the SHOW_ARGS define is provided to do some debugging on that portion of the code. A similar variation is: : : if ( x_flag ) #ifdef SYSV ; /* SYSV defaults to state x anyhow */ #else #ifdef BSD do_bsd_x( args ); #else #ifdef XENIX do_xenix_x( other_args ); #endif #endif #endif : : where one porting variation generates an empty then statement. -- "Software and cathedrals are much the same - | John Macdonald first we build them, then we pray" (Sam Redwine) | jmm@eci386