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

[Bruce Evans]

On Sun, 15 Feb 2015, Bruce Evans wrote:

> On Sat, 14 Feb 2015, Pedro Giffuni wrote:
>> _____
>> ...
>> BUGS
>> The alloca() function is machine and compiler dependent; its use is dis-
>> couraged.
>
> This became out of date with VLAs in C99.  Except for scopes, compilers
> must have slightly more complications to support VLAs than alloca().
> They might still not support alloca().  But FreeBSD never used ones that
> don't.  That it would never use them was not so clear when this man page
> was written.

I found this interesting related problem on the web: inline functions
with alloca() in them may blow out the stack.

But this is only with broken compilers.  For inline functions to work,
they must have the same semantics as when they aren't inlined,
especially when they are automatically inlined.  This means that any
alloca()'ed space in an inline function must be freed at the end of
that function, not at the end of its caller.

clang handles this correctly by doing requested inlining, and freeing
in the right place.  gcc documents the problem and normally refuse to
do requested inlining in functions that call alloca().  However, gcc
can be broken by forcing the inlining using __always_inline.  gcc-4.2
silently produces the stack-blowing code.  gcc-4.8 warns that the
forced inlining might be wrong.

alloca() in any macro would have this problem, unlike a [VL]A in a
compound statement in a macro.

Bruce