2 lint questions

[Chris Torek]

In article <5967 at ingr.com> boyd at ingr.com (Boyd Nation) writes:
>1)  How does one prevent lint from issuing a warning message about possible
>pointer alignment problems given the following line of code:
>
>	x = (blivet *)malloc(sizeof(blivet));
>
>given that everything is declared and defined correctly?

As the `BUGS' section of any whole% lint(1) manual page says, `There
are some things you just *can't* get lint to shut up about.'
/*NOSTRICT*/ was supposed to keep it quiet in this particular case; but
NOSTRICT is not implemented in many (all?) lints, and in any case it is
the wrong solution.
-----
% Some vendors remove or rename the `BUGS' sections from manuals.
-----

There is a solution, albeit an ugly one:

	#ifdef lint
	/* keep lint quiet about malloc() */
	static void _lint_malloc(x) unsigned x; { x = x; }
	#define malloc(x) (_lint_malloc(x), 0)
	#endif /* lint */

Then your call changes from

	x = (blivet *)malloc(sizeof(blivet));

to

	x = (blivet *)(_lint_malloc(sizeof(blivet)),0);

which puts a nil pointer of type `pointer to blivet' into x.
Since lint is fairly stupid,

	if (x == NULL)

does not cause warnings about constants in conditional contexts,
even if you wrote

	if ((x = (blivet *)malloc(sizeof(blivet))) == NULL)

It would be nice if compiler vendors included something like the
`#ifdef' code above in <stddef.h> (the _lint_malloc function would
have to move to the regular lint library).

>2)  Is there any way to get lint to detect a closed loop of code which can
>never be called?

Lint would need to do call graph analysis to find these; I have never
seen one that does.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7163)
Domain:	chris at mimsy.umd.edu	Path:	uunet!mimsy!chris