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>