Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!virtech!cpcahil
From: cpcahil@virtech.uucp (Conor P. Cahill)
Newsgroups: comp.lang.c
Subject: Re: FAQ - malloc array - clarify
Keywords: malloc, Sun, lint
Message-ID: <1990Sep08.022034.8444@virtech.uucp>
Date: 8 Sep 90 02:20:34 GMT
References: <8056@helios.TAMU.EDU>
Reply-To: cpcahil@virtech.UUCP (Conor P. Cahill)
Organization: Virtual Technologies Inc., Sterling VA
Lines: 36

In article <8056@helios.TAMU.EDU> jdm5548@diamond.tamu.edu (James Darrell McCauley) writes:
>  int i, nrows=10, ncolumns=10;
>  double **array;
> 
>  array = (double **)malloc(nrows * ncolumns * sizeof(double *));
                             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
While this has nothing to do with your lint problems, I think this should be:

   array = (double **)malloc(nrows * sizeof(double *));

>  for(i = 0; i < nrows; i++)
>    array[i] = (double *)malloc(ncolumns * sizeof(double));
>}
>/* 
>/* output from lint:
>test.c(8): warning: possible pointer alignment problem
>test.c(10): warning: possible pointer alignment problem

This you will always get from lint.  The problem is that malloc is defined
as returning a pointer to char which has looser alignment requirements than
pointer to pointer.  Since malloc guarrantees that the result is suitably 
alligned for all data types, you can ignore this message.

>malloc, arg. 1 used inconsistently	llib-lc(383)  ::  test.c(8)
>malloc, arg. 1 used inconsistently	llib-lc(383)  ::  test.c(10)

This is caused by the argument to malloc being unsigned, not signed.  A
cast in your code will fix this.




-- 
Conor P. Cahill            (703)430-9247        Virtual Technologies, Inc.,
uunet!virtech!cpcahil                           46030 Manekin Plaza, Suite 160
                                                Sterling, VA 22170