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
_______________________________________________
svn-src-head@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"

Reply via email to