Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uwm.edu!cs.utexas.edu!tut.cis.ohio-state.edu!att!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.unix.programmer
Subject: Re: hiding lint's ravings (was Re: FAQ - malloc array - clarify)
Keywords: malloc, Sun, lint
Message-ID: <17903@haddock.ima.isc.com>
Date: 10 Sep 90 00:27:17 GMT
References: <8056@helios.TAMU.EDU> <1990Sep08.022034.8444@virtech.uucp> <8086@helios.TAMU.EDU>
Reply-To: karl@kelp.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 33

In article <8086@helios.TAMU.EDU> jdm5548@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@kelp.ima.isc.com or ima!kelp!karl), The Walking Lint