alloca() portability

[house ron]

paulb at ssd.csd.harris.com (Paul Beusterien) writes:

>In article  <27608 at 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 at zeus.usq.edu.au)
(By post: Info Tech, U.C.S.Q. Toowoomba. Australia. 4350)