From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> In-reply-to: Your message of "Mon, 16 Jan 2012 15:11:24 EST." <4F14846C.4040706@gmail.com> References: <4F14846C.4040706@gmail.com> Date: Mon, 16 Jan 2012 15:18:58 -0800 From: Bakul Shah Message-Id: <20120116231858.5B7891CC32@mail.bitblocks.com> Subject: Re: [9fans] assembly syntax in plan 9 Topicbox-Message-UUID: 5e21f7c6-ead7-11e9-9d60-3106f5b1d025 On Mon, 16 Jan 2012 15:11:24 EST "Joel C. Salomon" wrote: > On 01/16/2012 02:03 PM, Bakul Shah wrote: > > On Jan 16, 2012, at 10:51 AM, Greg Comeau 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()!