alloca

[hjm]

Two points about alloca:

   - not knowing the size of the stack frames is a big pain on a non-virtual
     memory machine.  If a program is non-recursive, then it possible to
     calculate at compile time the maximum stack usage and allocate just that
     space for the stack in a multi-tasking system, minimising memory usage
     and avoiding the need for stack relocation or extension.

   - why have two mechanisms for memory allocation when one will do?  malloc()
     is perfectly adequate in that it gives you the memory you require when
     you require it (if it's available) and free() lets you give it back when
     you want to.  Simple to implement portably, and easy to understand.  If
     you find it difficult to remember to give back memory at the end of a
     function then why not have a function which does the following:

	alloc_and_call (func, size) void (*func)(); int size;
	{
	  char *p;

	  p = malloc(size);
	  func(p);
	  free(p);
	}

     OK, so that's not perfect.  Parameter passing is a problem, but just a
     small part to add on.  Portable code for those people who can't remember
     to deallocate stuff they asked for.

     When physical memory gets tight, how do you propose that malloc and 
     alloca should talk to each other so that they don't tread on each other's
     toes?

As a general principle, I would advocate one method for doing something rather
than two if there is any choice at all.  Uniformity is something that aids
thinking and allows people to solve the real problems of writing the code to
do the job, and not to waste time wondering "should I use malloc or alloca".

	Hubert Matthews