alloca (was: libpw.a)

[Leslie Mikesell]

In article <10090 at smoke.BRL.MIL> gwyn at brl.arpa (Doug Gwyn) writes:

>>>To repeat: alloca is EVIL.
>>It doesn't have to be.

>You appear to have missed the previous discussion.
>alloca() simply cannot be reasonably provided in some C environments.
>If your application depends on alloca(), you have limited its portability.
>There is no situation I know of when use of alloca() is necessary.

Likewise there is no situation where the use of local variables is necessary.

There are two situations which are helped by the use of alloca():
1) dividing the dynamically allocated space into reasonably sized chunks
to reduce the time malloc() and free() need to search their lists, and
2) providing the ability to longjmp() out of a function (or just return)
with the no longer needed memory automatically released (just like local
variables).

In addition to this, alloca() is conceptually the same as using local
variables, malloc() is conceptually the same as using global varibles
and the same arguments for the use of each should apply.  Consider that
if you longjmp() out of a function that no longer needs its malloc()'ed
memory you *must* have stashed a global pointer in order to free it.
Now, why can't the machines that can dynamically allocate space off the
stack have an ordinary alloca() and those that can't provide a fake one
which uses malloc() but tags the blocks such that calling alloca() or
malloc() again will automatically free() any blocks alloca()'ed from
a function that is no longer active?  This would at least provide the
conceptual advantages if not the efficiency.

Les Mikesell