Further observations regarding alloca on i586-pc-linux-gnu
Martin von Loewis
Sun Aug 23 11:19:00 GMT 1998
> This is well known. What is not clear to me though, is whether
> it is a bug in the compiler or in the test.
I've tried to find documentation on the semantics of alloca in gcc,
but didn't found much. The portable alloca.c says
>> allocate automatically reclaimed memory
and this is how most users probably see it. extend.texi says that the
memory is available until the end of the function.
> The test is effectively relying on the order in which arguments are
> evaluated, which is wrong.
No, it doesn't. It requests memory reclaimed at the end of the
function. As it turns out, the compiler might overwrite the memory
> Note that the exact same effect would happen if alloca was not a
No, it wouldn't. The portable alloca would not reclaim the memory
until the next alloca call, and then only if the previous call was
deeper on stack.
> Note that if you mind sequence points like you ought, you get
> correct results.
The original example was using alloca as a default argument. It seems
that g++ currently does not support that, an alloca call must occur as
a full expression in itself, not inside a full expression.
So it seems g++ should either detect this violation in alloca usage,
or be fixed to support alloca in subexpressions.
More information about the Gcc-bugs