Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!xanth!mcnc!rti!talos!kjones
From: kjones@talos.UUCP (Kyle Jones)
Newsgroups: comp.unix.wizards
Subject: alloca     (was Re: libpw.a)
Message-ID: <517@talos.UUCP>
Date: 24 Apr 89 15:16:17 GMT
References: <157@dftsrv.gsfc.nasa.gov> <10013@smoke.BRL.MIL> <8184@chinet.chi.il.us> <1250@frog.UUCP> <564@aablue.UUCP> <1883@thor.acc.stolaf.edu>
Reply-To: kyle@xanth.cs.odu.edu (Kyle Jones)
Distribution: na
Organization: Philip Morris Research Center, Richmond, VA
Lines: 16

In article <1883@thor.acc.stolaf.edu> mike@mike@stolaf.edu writes:
 > I'm the author of GNU grep, and I firmly believe that alloca is Evil.
 > Don't use it in new programs!

Why not?  So compiler vendors can stop supporting it?  Alloca is a very
useful function to have on systems that can support it.  I believe that
it is useful enough that it should be demanded on all systems capable of
supporting it.  For the others, I can cobble a replacement that uses
malloc and put wrappers around setjmp and longjmp calls to free this
memory.  I've done this before, it's not hard.  But using a the alloca
where available is a big win in terms of time taken to allocate the
memory and programming ease when cleaning up after a longjmp.

Why throw alloca away on systems that can support it?  It's a simple
idea, stupefyingly easy to implement on stack-based machines, and makes
a certain class of programming tasks easier.