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