Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!dogie.macc.wisc.edu!uwvax!rutgers!bellcore!faline!thumper!ulysses!mhuxo!mhuxu!att!chinet!les From: les@chinet.chi.il.us (Leslie Mikesell) Newsgroups: comp.unix.wizards Subject: Re: alloca (was: libpw.a) Message-ID: <8261@chinet.chi.il.us> Date: 22 Apr 89 03:25:55 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> Reply-To: les@chinet.chi.il.us (Leslie Mikesell) Organization: Chinet - Public Access Unix Lines: 32 In article <10090@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes: >>>To repeat: alloca is EVIL. >>It doesn't have to be. >You appear to have missed the previous discussion. >alloca() simply cannot be reasonably provided in some C environments. >If your application depends on alloca(), you have limited its portability. >There is no situation I know of when use of alloca() is necessary. Likewise there is no situation where the use of local variables is necessary. There are two situations which are helped by the use of alloca(): 1) dividing the dynamically allocated space into reasonably sized chunks to reduce the time malloc() and free() need to search their lists, and 2) providing the ability to longjmp() out of a function (or just return) with the no longer needed memory automatically released (just like local variables). In addition to this, alloca() is conceptually the same as using local variables, malloc() is conceptually the same as using global varibles and the same arguments for the use of each should apply. Consider that if you longjmp() out of a function that no longer needs its malloc()'ed memory you *must* have stashed a global pointer in order to free it. 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? This would at least provide the conceptual advantages if not the efficiency. Les Mikesell