🚀 go-pugleaf

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.

 > Case in point.  I recently ported gdbm1.1 to System V R3.2.  The source
 > initially used alloca() in several places.  In doing so, it required me
 > to link in an additional library, that wouldn't obviously needed
 > normally.
 > 
 > With a little careful study, I was able to replace all occurrences of
 > alloca() with calls to malloc() and free().  This process took perhaps
 > an hour.  Why couldn't the original programmer have done this, and
 > created a much more portable program?

Is your code robust enough to reclaim the malloc'd memory, even
if the containing function does not exit normally, e.g. calls
longjmp()?  With alloca() the programmer doesn't have to worry
about this.