aeb@turing.UUCP (10/17/84)
It is a good idea to have a program checking layout just as lint checks
syntax. But cchk is not what we need.
Some trivial comments on cchk:
- STACKSIZ is too small and should be increased to at least 100
- When reading stdin no line numbers are given.
- When checking several files the error reporting for files after
the one containing the first error is buggy.
- It gets into an infinite loop when confronted with a non-closed
comment. (Ha! A new contest - what is the shortest input
making cchk loop or making it dump core?)
- It does not complain about wrong indentation for lines not
containing parentheses like break; or continue;
- It complains about constructions like
if(this_is_true && and_this_as_well && and_also_this &&
we_must_do_something) {
do_something();
}
where the closing brace is in the right place, but the open brace
is not on the same line as the if it belongs to.
I fixed the problems mentioned above (and some others) but found the
resulting program still almost useless for checking large pieces of
C code - most of the error messages are caused by cchk's misunderstanding
and not by objectionable coding practices.
Of course the true fault of cchk is that it doesnt understand what it
is reading - it does not even treat lines starting with a # specially.
Braces that occur in the initialization of an array of large structures
are aligned in a different way than braces for flow control or block
structure. Cchk as it is now cannot complain about unexpected increase in
indentation level, for "expected" depends on the surrounding syntax.
Let us hope somebody is active enough to do the real job and use lex/yacc
plus a C grammar.
--
Andries Brouwer -- CWI, Amsterdam -- {philabs,decvax}!mcvax!aeb