Path: utzoo!attcan!uunet!cs.utexas.edu!samsung!uakari.primate.wisc.edu!uflorida!travis!paulb From: paulb@ssd.csd.harris.com (Paul Beusterien) Newsgroups: comp.lang.c Subject: Re: alloca() portability Message-ID: Date: 12 Nov 90 18:13:57 GMT References: <14377@smoke.brl.mil> <9122@ncar.ucar.edu> <27537@mimsy.umd.edu> <1990Nov09.233527.7489@chinet.chi.il.us> <27608@mimsy.umd.edu> Sender: news@travis.csd.harris.com Organization: Harris Computer Systems Division Lines: 21 In-reply-to: chris@mimsy.umd.edu's message of 12 Nov 90 06:06:35 GMT In article <27608@mimsy.umd.edu> Chris Torek writes : > It is rather circular, but the circle exists now and as a result it is > hard to break out of it. In my opinion, when breaking such a circle it > is best to do so cleanly, and (also my opinion) alloca is *not* clean. In my opinion alloca is the cleanest way to allocate memory that is needed for the lifetime of a single routine. Why go to the trouble of allocating memory from a generic place when it can be associated with the routine that uses it? There can be major time and space gains by using alloca instead of malloc and free. It is obviously faster to adjust a stack pointer than to search an available list and free it back up. Also, space may be saved because of less fragmentation. If another routine has already alloca'ed space or there has been a lot of recursion in some other place in the program, the alloca may be completely free because the stack space has already been allocated. -- Paul Beusterien paulb@ssd.csd.harris.com Harris Computer Systems {uunet,mit-eddie,novavax}!hcx1!paulb Ft. Lauderdale, FL voice: (305) 973 5270