Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site watvlsi.UUCP
Path: utzoo!watmath!wateng!watvlsi!ksbszabo
From: ksbszabo@watvlsi.UUCP (Kevin Szabo)
Newsgroups: net.lang.c
Subject: Re: Dumb question on dyn. mem. alloc (if(hate(novices)) dont_read();)
Message-ID: <2624@watvlsi.UUCP>
Date: Sun, 21-Jul-85 17:24:24 EDT
Article-I.D.: watvlsi.2624
Posted: Sun Jul 21 17:24:24 1985
Date-Received: Mon, 22-Jul-85 08:32:49 EDT
References: <1035@homxa.UUCP> <5802@utzoo.UUCP>
Reply-To: ksbszabo@watvlsi.UUCP (Kevin Szabo)
Organization: VLSI Group, U of Waterloo
Lines: 40
Summary: 

>> ...  It seems that no
>> matter how I declare the function calloc() or how I typecast in
>> the returned pointer, I get a warning from lint that I have
>> a "possible pointer alignment problem." 

What options are you passing to LINT? If you are on a BSD system, don't
use the -c option.  If you are on sys3/sys5 use the -c option.

Henry Spencer says:
>Ignore the messages...
>...the "lint" entry in the Makefile for any program
>of mine that uses malloc() a lot tends to read something like:
>	lint foo bar bletch | egrep -v 'possible pointer alignment'

Actually, you can get LINT to do a little bit more checking for you,
and thereby find a few of those irritating little bugs where you
allocate a structure of the wrong size while casting it to the correct
pointer type.  I find that LINT generally believes a cast to a pointer
type, as long as you don't/do use the -c option (on a BSD/SYSIII system).
The -c option tells lint to complain (or not complain) about all 
non-portable pointer mismatches and questionable pointer casting.

You can then automatically allocate a structure and cast it
using a nice little macro:

#define ALLOC( x )	((x *) malloc( sizeof(x)))

and a companion:

#define FREE( x )	free((char *) ( x ))

The ALLOC macro behaves like pascal's "new( x )" builtin, and reduces the
chances of a typographical error such as:
	ptr_type1 = (ptr_type1) malloc( sizeof (type2));
We started using the macros after we spent two days searching for exactly
this type of error.  Argh.

			Kevin
-- 
Kevin Szabo' watmath!wateng!ksbszabo (U of W VLSI Group, Waterloo, Ont, Canada)