FAQ - malloc array - clarify

[Peter Holzer]

karl at haddock.ima.isc.com (Karl Heuer) writes:

>In article <1806 at tuvie> hp at vmars.tuwien.ac.at (Peter Holzer) writes:
>>The lint libraries are ASCII files on our system. Are they in a compiled 
>>form on yours ?

>Common practice on modern machines is to supply a compiled form (llib-lc.ln)
>as well as the ASCII form (llib-lc).  You probably have both, and just never
>noticed.

Yes. Now that you told me, I found them.

>>cpcahil at virtech.uucp (Conor P. Cahill) writes:
>>>In article <1803 at tuvie> hp at vmars.tuwien.ac.at (Peter Holzer) writes:
>>>>cpcahil at virtech.uucp (Conor P. Cahill) writes:
>>>>>This is caused by the argument to malloc being unsigned, not signed.  A
>>>>>cast in your code will fix this.
>>>>No! Don't fix your code, which is correct. 
>>[The problem is that sizeof() incorrectly returns a signed int, and size_t is
>>defined that way in <sys/types.h>, but malloc() expects an unsigned int.]
>>Now if I want to shut up lint about [malloc(sizeof(x))], what should I cast
>>the argument to malloc to?
>> [Various types and why they don't work deleted]

>Don't cast it at all!  The idea is to make the code *correct*, not to get rid
>of spurious warnings caused by a known compiler/lint bug.

Just what I said.

>>[You could change the lint library to declare the argument to be int]

>This would create a new warning for correct code (malloc(n*sizeof(T)), where n
>is an unsigned variable).  Better to fix the compiler, if possible.

Ok, I hereby withdraw my proposal.
New proposal:
	Complain to your compiler/lint vendor and wait for a new
	release.

>>(The other possibility is not to use lint, which I am forced to do, because
>>lint gags on my prototypes, but in general, I would not recommend that).

>Lint is commonly implemented as a shell script.  Find the place where it does
>something like "cpp | lint1", and insert a filter that converts ANSI-isms to
>forms that are acceptable to K&R-based lint.  (I currently use a sed script to
>change "void *" to "char *", and a deprotoizer that's tuned to my personal
>coding style.)

I will try it. My deprotoizer is a little less strict about white space
than yours (but twice the size), but it doesn't handle pointers to
functions either, so there will be some programs where it won't work.
If it does work in most cases I'll be happy, though.

The best solution would be a GNU lint, which does understand ANSI C and
GNU extensions (e.g. volatile void exit (int);).

PS: I like "Heuer's Law". If I hadn't seen it in some other
guy's signature already, I would have put it into mine.

--
|    _	| Peter J. Holzer			| Think of it	|
| |_|_)	| Technische Universitaet Wien		| as evolution	|
| | |	| hp at vmars.tuwien.ac.at			| in action!	|
| __/  	| ...!uunet!mcsun!tuvie!vmars!hp	|     Tony Rand	|