svn commit: r278737 - head/usr.sbin/flowctl

[John Baldwin]

On Saturday, February 14, 2015 02:53:48 PM Pedro Giffuni wrote:
> On 02/14/15 13:33, Ian Lepore wrote:
> > 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.
> 
> Because it's non-standard and the alloca(3) man page discourages it:
> _____
> ...
> BUGS
> The alloca() function is machine and compiler dependent; its use is dis-
> couraged.
> 
> ____
> 
> It is not disappearing anytime soon though, some even say the man
> page is wrong.

Given all the alternative implementations and concerns, it seems like alloca() 
is a lot simpler to use.  I suspect it isn't going away anytime soon, either.

-- 
John Baldwin