daw@cbnewsh.att.com (David Wolverton) (06/28/90)
In article <16972@haddock.ima.isc.com>, karl@haddock.ima.isc.com (Karl Heuer) writes: > In article <1990Jun24.154126.17713@jarvis.csri.toronto.edu> flaps@dgp.toronto.edu (Alan J Rosenthal) writes: > >daw@cbnewsh.att.com (David Wolverton) writes: > >>The SVR4 lint "does the right thing" on calls to malloc(), but > >>then SVR4's header files declare "void *malloc(size_t);" too. > >>A lintpragma isn't necessary if you support ANSI C. > > >I assume you're referring to the fact that lint can recognize malloc() as a > >special case. > > No, I believe he's saying that `void *' automatically kills the warning. As I > already noted in a parallel article, this really solves the wrong problem. Karl is probably right. But then, I'm not interested in trying to defend the design goals of the SVR4 lint, because I didn't design it. Dave Wolverton <claimer>
levy@mtcchi.uucp (2656-Daniel R. Levy(0000000)0000) (07/02/90)
scottl@mercury.sybase.com (Scott Luebking) writes:
<One trick I found helpful to get around the lint/malloc problem is to include:
<#if LINT
<#define malloc(x) NULLPTR
<#endif /* LINT */
<at the beginning of the file or in a central include file. When lint is
<executed, the LINT macro is defined.
Maybe this is a stupid question on my part, but... might this elicit complaints
about test of a constant (you DO check the result of malloc, don't you)?
--
Daniel R. Levy
Memorex Telex Corporation
Naperville IL
..!uunet!tellab5!mtcchi!levy