Path: utzoo!attcan!uunet!munnari.oz.au!brolga!bunyip.cc.uq.oz.au!zeus!s64421 From: s64421@zeus.usq.EDU.AU (house ron) Newsgroups: comp.lang.c Subject: Re: alloca() portability Message-ID: Date: 13 Nov 90 09:53:59 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> Lines: 31 paulb@ssd.csd.harris.com (Paul Beusterien) writes: >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. ABsolutely! It is a crying shame that alloca is not in ANSI. Of course the real culprit is the absence of declarations with variable bounds (int a[n]). Efficiency arguments about _that_ one really are rather pathetic, given that all sane computers nowadays have a good efficient stack. BTW, I have found that alloca can usually be programmed for most compilers, provided you promise yourself only to use it immediately on entry to a function which declares at least one variable. Optimisers are pretty hard put to foul that up. -- Regards, Ron House. (s64421@zeus.usq.edu.au) (By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)