Yet Another Lint Foul-up

[Doug Gwyn]

In article <1298 at tank.uchicago.edu> vevea at paideia.UUCP (Jack L. Vevea) writes:
> Otherwise, it would seem to me that any concern with the message would
> be evidence of your being a slave to lint; why else be concerned when
> you _know_ that the warning is inconsequential?

Certainly if a random result really IS returned to the environment,
it's a bug, because (at least in the UNIX world) the termination
status of a process is a very important thing.

Therefore let's assume you really do know that "lint" is simply
mistaken, because of some limitation such as not realizing that
exit() never returns.  In this case, there is STILL a very good
reason for wanting to "shut lint up":  The careful portable
programmer expects absolutely NO output from "lint".  (In fact,
I achieve this nearly all the time.)  To get in the habit of
ignoring "lint" warnings is to defeat the purpose of "lint".
What if some time the "random value returned to execution
environment" warning is valid?  You'll just ignore it, but those
of us who have carefully arranged for no expected "lint" output
will certainly investigate this unexpected warning.

Ignoring certain "lint" output that could have been avoided is
one bad habit.  There is another one in the opposite direction:
Some C programmers use tricks to "shut lint up" rather than
fixing a genuinely non-portable aspect of their code.  There
aren't many cases where "lint" must be outwitted; trying to
outwit it in other cases is a mistake.

Here are things that I don't know of any way to keep "lint" from
unjustly complaining about without deliberately sabotaging it:

	return from malloc() being used other than as a (char *)

	functions like exit() that don't return

	loops that will never terminate but not patently so

	use of pointer casts

I do know how to outwit "lint" in these cases, but one needs to
be careful doing that in order not to disable a valid warning.