🚀 go-pugleaf

According to kyle@cs.odu.edu:
>Certain memory management takss are made much easier by using
>alloca(), as opposed to malloc() and free().

True, some things become easier.  But ease of use isn't the point.  If
simplicity of programming is your only goal, then you're using the
wrong language.  Otherwise, simplicity must be balanced against other
criteria, such as portability and speed.

>Portability needn't suffer, because portable substitutes for alloca()
>exist, and these can be used on machines that don't support it.

This analysis is incomplete.  So-called "portable" alloca
implementations are never faster than malloc(), since they call
malloc() to do the actual allocation.  So using alloca() is fast with
some architecture+compiler combinations, it is actually slow with
others.

I have used alloca() in code that is intrinsically non-portable, and
which is therefore not subject to normal portability concerns.  But
for all other code, I just use malloc().  It saves everyone a lot of
time and trouble.

I agree with the original poster.  The world would be a Better Place
if the GNU subroutines -- regex, glob, readline, etc. -- would avoid
the use of alloca().
-- 
Chip Salzenberg at ComDev/TCT   <chip%tct@ateng.com>, <uunet!ateng!tct!chip>