Funny mistake

[Doug Gwyn]

In article <13584 at helios.TAMU.EDU> byron at archone.tamu.edu (Byron Rakitzis) writes:
>I have had uniformly bad experience with lint. Not only is it an outdated
>tool (I have not seen an ansi lint) but many of its warnings are not
>pertinent to the code. For example, the "pointer alignment" problem with
>every call to malloc, and the "returns a value which is ignored" problem
>with every call to printf. A user of lint must wade through a whole bunch
>of garbage error messages to evaluate whether the code really needs fixing.
>And adding gratuitous casts to void before every printf is a solution that's
>worse than the problem, IMHO.

Rather than fighting "lint", it is much more productive to learn how
to exploit it.

(1)  I have heard that SVR4 includes, for the first time in the official
UNIX distribution, both an ANSI-conforming (at least that's the intent)
C implementation AND a corresponding version of "lint".

(2)  There are several solutions to the malloc() "pointer alignment"
warning, which I agree is a drawback to traditional "lint".  Some versions
of lint() support additional comment-flags that can be attached to lint-
library definitions to indicate malloc()-like, or printf()-like interfaces.
Or, your application can deal with this directly, for example as we did in
the MUVES implementation, whose memory-manager interface header contains
kludges like:
	#ifdef lint	/* shut "lint" up */
	#define MmVReallo( o, n, t )	\
		((void)MmDebug( (n) + (int)sizeof(t) ), o)
	#else
	#define MmVReallo( o, n, t )	\
		((t *)Mm_RAllo( (pointer)(o), (n) * (unsigned)sizeof(t) ))
	#endif
Or, you could just learn to live with the handful of additional spurious
warnings, so long as you check each of them out to be SURE that it is due
to "lint"'s lack of knowledge about malloc()'s special properties.

(3)  "Returns a value which is ignored" is a legitimate warning in most
cases (i.e. those where a failure of the function is reflected in its
returned value).  This is certainly true for printf(), which CAN FAIL
and therefore should have its return value checked in robust applications.
Much of the time, the value of functions such as strcpy() is not of much
use (although I personally make frequent use of it), so in those cases it
would be useful for "lint" to support some comment-flag on the definition;
I don't know if this particular flag is supported by any versions of
"lint", but it certainly could be.

(4)  Anyone who simply adds a bunch of (void) casts to existing code has
missed the boat.  The time to consider whether or not it is necessary to
examine the value returned by a given function invocation is WHEN THE
CODE IS BEING WRITTEN.  Use of (void) there serves as a definition note
that the programmer has considered the issue and decided that it is safe
to ignore that specific return value.  If you follow such a procedure,
then ANY "returns a value which is ignored" warning from "lint" indicates
a genuine error, or at least a programmer oversight.

>I strongly believe it is up to the compiler to take care about safeguarding
>the use of the language which it translates, even if this means flagging
>valid code which has been *probably* erroneously typed in.

Actually, if a compiler flags such code of MINE, it is *probably* the
compiler that has made the mistake.  I really don't appreciate C
compilers that cater to novices at the expense of experts.  Options to
turn on "novice mode" are okay, but they MUST be OPTIONS.