Okay, we're getting way OT here..
(...) I like the --Wall flag. I think that
it's conceptually better than the 'lint' program used by other unices (or is
it just Sun?). (...)
Nope(*). lint by itself is a very nice tool for checking code for, let's say
valid but dubious C code. Consider the following two examples:
switch (ayaken) {
case BANZAI:
fprintf(stderr, "woohoo! banzai!\n");
default:
abort();
}
and
switch (ayaken) {
case BANZAI:
fprintf(stderr, "woohoo! banzai!\n");
/* FALLTHROUGH */
default:
abort();
}
gcc -Wall won't complain about either of these (except BANZAI/ayaken
might be an enum and we don't cover all of it here), but the second
case is lint-safe. It also documents that it is *no* forgetting of the
break;. lint checks code on another dimension than gcc. It also catches
(some/many/an awful lot of) problems gcc doesn't/can't/won't ever. The
use of lint is totally orthogonal to (g)cc -W<anything>. I think there's
a fair amount of documentation about the use of lint and where it makes
sense and where it doesn't. AFAIK there's even an O'Reilly Book (Code
checking with lint or sth similar).
I wouldn't call gdb (an absolutely orthogonal tool not having anything
to do with gcc except for reading debugging information from the executable
which gcc put there -- any compiler can do that) a useless tool either ...
Nor gprof, dmalloc or other allocation checker (programs or libraries).
Those are just a bunch of development tools, and using them wisely, and
knowing how to use them, WILL improve the quality of (C-) code you are
writing. Agreeing to their standards (most of the time) means agreeing to
what commonly is viewed as 'good' C-Code.
With kind regards,
-Martin
(*): Any unix should have a lint, really. BSD has one, I suppose linux
has one, too (mutter: although my last base installation didn't even have
RCS!!!), and it's fine solaris has one, too.