Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!voder!pyramid!leadsv!laic!ik
From: ik@laic.UUCP (Ik Su Yoo)
Newsgroups: comp.lang.c
Subject: Re: hiding lint's ravings (was Re: FAQ - malloc array - clarify)
Keywords: malloc, Sun, lint
Message-ID: <881@laic.UUCP>
Date: 9 Sep 90 23:03:46 GMT
References: <8056@helios.TAMU.EDU> <1990Sep08.022034.8444@virtech.uucp> <8086@helios.TAMU.EDU>
Organization: Lockheed AI Center, Menlo Park
Lines: 33

> 
> Well, I can just ignore warnings like this, but those who review
> my code (professors, employers, clients) are not likely to. It makes
> an bad impression and frankly, I find it a little embarrassing.
> (I'm embarrassed for those who publish code in which lint detects
> things like unused arguments, etc). I could just:
> #ifndef lint
>    m = (double *) malloc(...
> #endif
> but before long, the code looks disgusting.  Do you just ignore
> warnings like this and remain confident in your code, or do you
> do your best to work around them?
> 

Actually, I'm not at all embarrassed by getting lint errors like unused
arguments etc., although I'm not sure why you'd want to show lint output to
your customers. Sometimes, I find it necessary to specify unused arguments
to achieve proper abstraction, consistent argument specification, etc.

There is a rather simple solution (which I picked up from the net) to your
code getting messy from using `ifndef' with each `malloc':

#ifndef lint
#define MALLOC(size)			(malloc(size))
#else
#define MALLOC(size)			(0)
#endif

-- 
|  Ik Su Yoo                                 |  Office: (415) 354-5584        |
|  Scientist @ Lockheed AI Center            |  Fax:    (415) 354-5235        |
|  Orgn. 96-20, Bldg. 259, 3251 Hanover St.  |  E-mail: ik@laic.lockheed.com  |
|  Palo Alto, CA  94304-1191                 |                                |