dan@kfw.COM (Dan Mick) (05/21/91)
Is it just Sun's lint that won't detect nested comments? I spent about six hours trying to find out why the 'code' below wasn't ever executed (some fumble-fingered vi late at night had added the space, and I didn't remember what else I'd changed for certain, I thought). /* comment * / code; /* comment */ I kicked myself for not using lint, and then discovered lint is silent about this construct. Are all lints this stupid (that is, do they all just accept output from cpp without checking the original source)?
guy@auspex.auspex.com (Guy Harris) (05/24/91)
>Is it just Sun's lint that won't detect nested comments? No. >Are all lints this stupid (that is, do they all just accept output from cpp >without checking the original source)? Most, if not all, "lint"s are basically modified versions of C compilers, and most, if not all, haven't been sufficiently modified that they can catch that problem.
bhoughto@pima.intel.com (Blair P. Houghton) (05/24/91)
In article <7992@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >Most, if not all, "lint"s are basically modified versions of C >compilers, and most, if not all, haven't been sufficiently modified that >they can catch that problem. Most, if not all, are hardly being modified at all, any more. I'm relegated on several machines to trusting the compiler warnings, since the compilers have been ANSIfied, but lint(1) is left in its previous state... gcc -Wall -<whatever> does a pretty good job, but the gnu library's so screwy I can't trust gcc as a *compiler*... (One for you trivia buffs: the oldest file in the gcc-1.39 source code is alloca.c, dated October 16, 1986 (think about it; gnu code nobody's altered in 5.5 *years*). For two points and a skip to the loo, name its author). --Blair "Who said it? What episode?"
harrison@csl.dl.nec.com (Mark Harrison) (05/24/91)
In article <1991May21.033422.21445@kfw.COM> dan@kfw.com (Dan Mick) writes: >Is it just Sun's lint that won't detect nested comments? > >Are all lints this stupid (that is, do they all just accept output from cpp >without checking the original source)? Try Gimpel's flexelint/PC lint: $ cat nested.c main() { /* foo * / /* bar */ } $ flint -e533 nested.c FlexeLint (U32) Ver. 4.00h, Copyright Gimpel Software 1985-1990 --- Object: /usr/local/lib/lc.lob --- Object: /usr/local/lib/lm.lob --- Module: nested.c nested.c 4 Warning 602: Comment within comment $ The flag -e533 turns off: nested.c 5 Warning 533: Return mode of main inconsistent with line 1 -- Mark Harrison | Note: harrison@ssd.dl.nec.com and harrison@csl.dl.nec.com | necssd!harrison are not operating at (214)518-5050 | present. Please forward mail through the | above address. Sorry for the inconvenience.
guy@auspex.auspex.com (Guy Harris) (05/27/91)
>>Most, if not all, "lint"s are basically modified versions of C >>compilers, and most, if not all, haven't been sufficiently modified that >>they can catch that problem. > >Most, if not all, are hardly being modified at all, any more. Definitely not all; System V Release 4 includes a new "lint" that allegedly handles ANSI C and has a bunch of other new stuff in it (including checks of the format string of "printf"-like routines against the argument list - i.e., they finally got around to implementing /*PRINTFLIKE*/ - as well as similar checks for "scanf"-like routines *and* a /*LINTED*/ construct that can help you shut "lint" up about some things - as I remember, it accepts something like /*TRUSTME*/ or some other amusing keyword as a synonym for /*LINTED*/).