Path: utzoo!censor!geac!torsqnt!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!zaphod.mps.ohio-state.edu!uakari.primate.wisc.edu!aplcen!haven!adm!smoke!gwyn
From: gwyn@smoke.brl.mil (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: alloca() portability
Keywords: portability, alloca
Message-ID: <14377@smoke.brl.mil>
Date: 7 Nov 90 11:13:00 GMT
References: <9032@ncar.ucar.edu> <499@taumet.com>
Organization: U.S. Army Ballistic Research Laboratory, APG, MD.
Lines: 17

In article <499@taumet.com> steve@taumet.com (Stephen Clamage) writes:
-There is more to it than the target machine.  Some compilers get a
-performance win by omitting frame pointers and leveling the stack only
-when actually needed.  The compiler keeps track of the top of the
-stack, and parameter and local variable references are relative to the
-current TOS rather than to the FP.  Upon return from a function, the
-stack is not necessarily popped -- it gets leveled only when different
-flow paths converge.  With such a stack management strategy, alloca
-cannot be implemented as a library routine -- it would have to be built
-into the compiler.

But that doesn't adversely affect my alloca() strategy.

It is worth repeating over and over:  DON'T WRITE CODE THAT USES alloca()!
I provided my alloca() implementation solely in support of existing code
that needs to be ported and for which fixing its use of alloca() would be
too painful.