Date: Sat, 14 Feb 2015 11:33:48 -0700 From: Ian Lepore <ian@freebsd.org> To: Gleb Smirnoff <glebius@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bruce Evans <brde@optusnet.com.au> Subject: Re: svn commit: r278737 - head/usr.sbin/flowctl Message-ID: <1423938828.80968.148.camel@freebsd.org> In-Reply-To: <20150214181508.GL15484@FreeBSD.org> References: <201502132357.t1DNvKda075915@svn.freebsd.org> <20150214193210.N945@besplex.bde.org> <20150214181508.GL15484@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 2015-02-14 at 21:15 +0300, Gleb Smirnoff wrote: > Bruce, > > On Sat, Feb 14, 2015 at 08:46:58PM +1100, Bruce Evans wrote: > B> Using VLAs and also the C99 feature of declarations anwhere, and extensions > B> like __aligned(), we can almost implement a full alloca() using the fixed > B> version of this change: > B> > B> /* > B> * XXX need extended statement-expression so that __buf doesn't go out > B> * of scope after the right brace. > B> */ > B> #define my_alloca(n) __extension__ ({ > B> /* XXX need unique name. */ \ > B> char __buf[__roundup2((n), MUMBLE)] __aligned(MUMBLE); \ > B> \ > B> (void *)__buf; \ > B> }) > > I like this idea. But would this exact code work? The life of > __buf is limited by the code block, and we exit the block > immediately. Wouldn't the allocation be overwritten if we > enter any function or block later? > Why put any effort into avoiding alloca() in the first place? Is it inefficient on some platforms? On arm it's like 5 instructions, it just adjusts the size to keep the stack dword-aligned and subtracts the result from sp, done. -- Ian
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1423938828.80968.148.camel>