Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.unix.wizards
Subject: Re: alloca
Message-ID: <10105@smoke.BRL.MIL>
Date: 23 Apr 89 01:37:59 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> <15945@rpp386.Dallas.TX.US> <10090@smoke.BRL.MIL> <8261@chinet.chi.il.us>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 20

In article <8261@chinet.chi.il.us> les@chinet.chi.il.us (Leslie Mikesell) writes:
>Now, why can't the machines that can dynamically allocate space off the
>stack have an ordinary alloca() and those that can't provide a fake one
>which uses malloc() but tags the blocks such that calling alloca() or
>malloc() again will automatically free() any blocks alloca()'ed from
>a function that is no longer active?

That's indeed more or less how my alloca() emulation works, but there are
numerous practical details that have to be taken care of, and such an
emulation simply cannot do the "right thing" under all circumstances.

Having gone through the exercise, I can assure you that alloca() is not a
good idea in C as it exists.  Some similar functionality might be useful
in a new programming language design (not C).  In writing many hundreds of
thousands of lines of C source code, I've never felt a strong enough need
for alloca() to cause me to use it.  Normally when I dynamically allocate
storage, it needs to hang around after the scope of the function in which
it was allocated terminates.  When it doesn't, normally automatic variables
suffice.  The few remaining instances aren't a great deal of trouble and
I use malloc()/free() for those.