hiding lint's ravings (was Re: FAQ - malloc array - clarify)

Karl Heuer karl at haddock.ima.isc.com
Mon Sep 10 10:27:17 AEST 1990


In article <8086 at helios.TAMU.EDU> jdm5548 at diamond.tamu.edu (James Darrell McCauley) writes:
>How do you professionals deal with insignificant(?) ravings from lint [like]
>test.c(x): warning: possible pointer alignment problem

This is caused by a long-standing bug in lint.  It could have been fixed long
ago, but this hasn't been a high-priority item with AT&T.  (It's "fixed" in
SVR4 by going full swing in the other direction; ANSI-lint now fails to report
some genuine alignment problems, as I understand the situation.)

And it's almost invariably a bad idea to muck up your code with a workaround:

>#ifndef lint
>   m = (double *) malloc(...
>#endif

Not only does this look ugly (and in my opinion, creates a *worse* impression
than the presence of a well-known spurious lint warning), but it can easily
lead to further problems.  For example, lint will now believe that "m" is
uninitialized.

But if you must have a workaround, one fairly clean one is to use a separate
interface for each type:
	#if !defined(lint)
	#define mkdouble()  ((double *)malloc(sizeof(double)))
	#define rmdouble(p) free((void *)p)
	#else
	extern double *mkdouble(void);
	extern void    rmdouble(double *);
	#endif
which might be a good idea anyway since it leaves room for more complex
constructors/destructors in a future revision.

Karl W. Z. Heuer (karl at kelp.ima.isc.com or ima!kelp!karl), The Walking Lint



More information about the Comp.unix.programmer mailing list