Path: utzoo!attcan!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!shadooby!samsung!gem.mps.ohio-state.edu!apple!snorkelwacker!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: lint vs varargs
Keywords: casts lint varargs
Message-ID: <15008@haddock.ima.isc.com>
Date: 27 Oct 89 18:39:50 GMT
References: <453@bdrc.UUCP>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 28

In article <453@bdrc.UUCP> jcl@bdrc.UUCP (John C. Lusth) writes:
>I have a lint question. Why does [SunOS] lint complain about varargs stuff?
>18:		va_start(ap);
>19:		format = va_arg(ap, char *);
>[without -c:]
>    test.c(19): warning: possible pointer alignment problem
>[with -c, the above and two more:]
>    test.c(18): warning: illegal pointer combination
>    test.c(19): warning: illegal pointer combination
>[After macro expansion, line 18 contains a cast from (int *) to (char *);
>shouldn't this always be legal?]

The problem here is that BSD-based lint, invoked with the -c option, believes
that *any* pointer cast is the moral equivalent of an uncasted assignment to a
non-matching pointer object.  If you can't live with it, don't use -c.

>On line 19, we get a cast of a char * to a char **. No guarantee that
>char ** is as wide as char *, so I guess the complaint, while annoying,
>is valid.

That's essentially correct (and the same problem occurs in USG-based lint).
This warning, and the corresponding one on malloc() calls, could be silenced
by a smarter implementation of lint and/or the header files.  I don't
recommend going to great lengths to fake it out, though.  Instead, I suggest
you report it to your vendor as a lint bug (which it is), and maybe it will
actually be fixed someday.

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