🚀 go-pugleaf

In article <1990May21.133554.12832@talos.pm.com> kyle@cs.odu.edu writes:
>Eric Schnoebelen writes:
> > I'm curious why (it seems like) all the gnu products seem to insist upon
> > using the alloca() function?  I was under the impression that it was
> > generally considered a vile, disgusting function and was generally
> > considered bad form to use it.
>
>I've heard people go on and on in comp.lang.c about the evil of
>using alloca(), but I remain unconvinced.  Certain memory
>management takss are made much easier by using alloca(), as
>opposed to malloc() and free().  Portability needn't suffer,
>because portable substitutes for alloca() exist, and these can be used on
>machines that don't support it.  But on machines that do support
>it, alloca() is a big win.

Excellent.  Since I'm not the only one unconvinced, let me add..

And if everyone would just offer it then it would be portable.  Some vendors,
however, seem to make a virtue of forcing the user to do all the hard work.
In fact, as you point out later, this becomes nearly impossible with
longjumps.  Howver, the compiler (on a non-stack system) knows all the
exit points and can prepare to free the memory for you.  This seems to
me a classic case of making the user do work the computer could do (and
Should do) much easier. 
How do users benefit by this lack of alloca availability?  I fail to see it.
Should there be users otherwise opposed to alloca then their solution is
obvious - just don't use it.  This is known as freedom of choice.
Let's not confuse the intransigence of vendors (large ones) with the rightness
or wrongness of alloca.  It isn't portable because they choose not to make
it so - not because it is, somehow, wrong.
-- 
Gary Bridgewater, Data General Corporation, Sunnyvale California
gary@sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary
The impossible we understand right away - the obvious takes a little longer.