alloca() portability

[Chris Torek]

In article <27608 at mimsy.umd.edu> I wrote:
>>>... the circle exists now and as a result it is hard to break out of it.
>>>In my opinion, when breaking such a circle it is best to do so cleanly,
>>>and (also my opinion) alloca is *not* clean.

In article <PAULB.90Nov12131357 at hcx2.ssd.csd.harris.com>
paulb at ssd.csd.harris.com (Paul Beusterien) writes:
>>In my opinion alloca is the cleanest way to allocate memory that is needed
>>for the lifetime of a single routine. ... [comparison with malloc deleted]

I disagree; however, we may well be on the same side:

>>There can be major time and space gains by using alloca instead of malloc
>>and free.  It is obviously faster to adjust a stack pointer than to search
>>an available list and free it back up.

There may be major correctness losses using alloca (as I wrote earlier,
any optimizing compiler can easily produce failing object code from
apparently-correct source code if that source code uses alloca).
(For fun, try compiling
	#include <stdio.h>
	void g(p, n) char *p; int n; { printf("got %lx, %d\n", (long)p, n); }
	void f(n) int n; { char *p = alloca(n); g(p, n); }
	int main() { f(23); return 0; }
and then the `optimized' version:
	#include <stdio.h>
	void g(p, n) char *p; int n; { printf("got %lx, %d\n", (long)p, n); }
	void f(n) int n; { g(alloca(n), n); }
	int main() { f(23); return 0; }
on fifty different architectures or so, and count success to failure
ratios.  You may have to compile the first without any optimisation.)

In article <s64421.658490039 at zeus> s64421 at zeus.usq.EDU.AU (house ron) writes:
>ABsolutely!  It is a crying shame that alloca is not in ANSI.  Of
>course the real culprit is the absence of declarations with variable
>bounds  (int a[n]).

Exactly.  Alloca is not the solution.  Alloca is a dirty hack.  The
solution to the problem at hand---namely, allocating local space, as
opposed to heap space, when the amount of space is not known at compile
time---should be something directly in the language.%  If you need `n'
`struct xyzzy's,

	struct xyzzy *p = alloca(n * sizeof *p);

is not the right answer, precisely because alloca is not known to the
compiler even though the things the compiler does with the stack (if
there is a stack; if not, all the arguments for local allocation fall
apart anyway; you might as well use a more general scheme) affect its
operation.  The stack frames produced by optimising compilers are NOT
easily predictable.
-----
% Note, all of this continues to be prefixed with an invisible `in
  my opinion'.
-----

Now, I personally remain uncertain as to whether gcc's approach is `good
enough', or whether Dennis Ritchie's proposal for NCEG is `best', or
whether simply declaring the name `alloca' to be a new keyword is the
`best' answer.  The main advantage that

	struct xyzzy p[n];

(where `n' is a variable) has over the alloca hack is that the former
fails noisily whenever it fails, while the latter fails quietly when
the compiler happens to disarrange the stack because that saves a few
instructions.

Alloca is, as Richard O'Keefe noted, a rather triangular wheel.  There
are rounder ones.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris at cs.umd.edu	Path:	uunet!mimsy!chris