back to the (ivory) tower

[Leo de Wit]

In article <16018 at brl-adm.ARPA> ted%nmsu.csnet at relay.cs.net writes:
>
>The 4.3 manual entry for alloca says:
>
>    BUGS
>         Alloca is both machine- and compiler-dependent; its  use  is
>         discouraged.
>
>On the other hand, alloca is often used and strongly supported by the
>gnu camp (n.b. heavy use in emacs and bison).
>
>It is true that proper use does simplify many aspects of avoiding hard
>limits for things like line lengths and such.  Alloca is also very
>handy in implementing stack gaps so that setjmp/longjmp can be used to
>do a weak implementation of coroutines and lightweight processes.
>
>It is also true that alloca is almost trivial to implement on most
>machines (say with a macro which expands to a single machine
>instruction to in(de)crement the stack pointer).
>
>What is the opinion of the masses?  Is alloca really such a problem
>across differing architectures?  Is it really that useful?

The masses (at least one of them 8-) give their opinion:
    When you need local variables whose sizes cannot be determined at compile
time, I think alloca() is ideal. Even when it is implemented as a function
instead of inline code, it will outspeed malloc() by orders of magnitude (I
think; BSD malloc is pretty nice though). (As for your single machine
instruction, the value of the new stack pointer has also to be taken. But I
will settle for 2).
    Besides, no more need of free; several modern architectures will restore
the stack pointer using the frame pointer.
    The lack of dynamic arrays in C could be partly removed by using alloca().
Also linked lists can benefit from it. The drawback is that you still have
to save things in global/static var's or on the heap when you want the function
to return (a pointer to) such a value.
    Taking the MC68000 as an example:
    If compilers follow the convention to address parameters by a positive 
offset from the link pointer, the local variables by a negative offset, and 
temporaries by an offset from the stack pointer (and most do that), and always 
use LINK/UNLK instructions to build/undo the stack frame, it works. However, the
last 'always' is not true; several compilers do not generate these instructions
if the function has no local variables; they use stack pointer relative 
addressing then to reach the parameters (saving a few instructions). In this 
case it is impossible to determine the position of the stack pointer when the 
function was called, as it is not saved and it is modified by alloca(); unless
someone makes a very clever alloca that keeps track of return addresses
and lets the calling function return to it (alloca) when it (the caller) has 
done (for instance; I'm just philosofing); but I doubt if it can be done 
without breaking existing code, and if it can be done for each machine/compiler.
    The problem with alloca() also is that, just because it does not come in 
pairs (like malloc() - free()) and some (or most ??!?) compilers) cannot 
support it (see above for some reasons) it is not portable.
    But I have a nice alternative: lets always use alloca() and a new function,
call it freea(), in pairs. Freea() should be called before leaving the function
(although it does not need to be in this case).
    For the compilers that support alloca():

#define freea()    /* a dummy */

    For those that don't:

#define alloca malloc    /* the oldies */
#define freea  free

    In both cases memory is allocated dynamically and freed upon return from
the function.

Everybody happy ?

	Leo.