On Mon, 16 Jan 2012 15:11:24 EST "Joel C. Salomon" <[email protected]> wrote: > On 01/16/2012 02:03 PM, Bakul Shah wrote: > > On Jan 16, 2012, at 10:51 AM, Greg Comeau <[email protected]> wrote: > >> What we do in problematic cases with Comeau is to generate code to > >> arrange for the allocation of the VLA on the heap. I'm not saying > >> this is perfect, but at least it gets the feature implementable and up > >> and running as "a portable implementation" versus perhaps not being > >> able to implement it at all on some platforms. > > > > How do you deal with longjmp? > > I recall reading the source for a (mostly-) portable alloca() that > checked where on the call-stack is was invoked from and released memory > for any alloca() invocation from lower on the stack. (The allocations > themselves were on the heap.)
You are probably referring to Doug Gwyn's portable alloca(). It relies on a static var to keep track of malloced alloca blocks. At first I thought it won't work in presence of threads but I guess if you used thread local storage for this, alloca() might be made to work but it is pretty bletcherous! Here's what Gwyn had to say about alloca() later.... [From https://www.securecoding.cert.org/confluence/display/seccode/08.+Memory+Management+(MEM) Douglas A. Gwyn Never use alloca. (See my comments in the Gnu source for alloca.) Under C99, you can use VLAs. Cince they require a FIFO lifetime model, neither is as general as dynamic allocation. Funny that he recommends using VLAs instead of alloca()!
