Path: utzoo!mnetor!uunet!lll-winken!lll-tis!ames!ll-xn!mit-eddie!uw-beaver!ubc-cs!faculty.cs.ubc.ca!manis
From: manis@faculty.cs.ubc.ca (Vince Manis)
Newsgroups: comp.sys.atari.st
Subject: Re: Big arrays in C
Message-ID: <2209@ubc-cs.UUCP>
Date: 26 Apr 88 18:37:06 GMT
References: <791@sun.mcs.clarkson.edu> <169@obie.UUCP>
Sender: nobody@ubc-cs.UUCP
Reply-To: manis@faculty.cs.ubc.ca (Vince Manis)
Organization: UBC Department of Computer Science, Vancouver, B.C., Canada
Lines: 28

You actually don't want to have large arrays be 'auto'. Such an array 
swells up the stack, and if you should make a procedure with a large
auto array be recursive, you will suddenly get many copies of the
array. This is rarely what is wanted. 

There is another method of getting an array which works on just about 
every compiler, and doesn't require that the array size be known at compile 
time. I use this method in preference to static arrays:

   typedef ... element_type;

   element_type *array;

   array = calloc(n_elements, sizeof(element_type));
   /* In MWC, you'd probably use lcalloc to get more than 64K.
      malloc/lmalloc are faster, because they don't initialise
      the array to 0. */

   array[42] = ... ;    /* Pointers can also be subscripted, so
                           you can just use it like an array. */

   free(array);         /* When you no longer need it. */


Vincent Manis                    | manis@cs.ubc.ca
The Invisible City of Kitezh     | manis@cs.ubc.cdn
Department of Computer Science   | manis@ubc.csnet
University of British Columbia   | {ihnp4!alberta,uw-beaver,uunet}!
<<NOTE NEW ADDRESS>>             |      ubc-cs!manis