Path: utzoo!attcan!uunet!munnari.oz.au!goanna!ok
From: ok@goanna.cs.rmit.oz.au (Richard A. O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: scope of malloc
Message-ID: <4251@goanna.cs.rmit.oz.au>
Date: 12 Nov 90 23:15:14 GMT
References: <1990Nov07.134942.7355@virtech.uucp> <3739@skye.ed.ac.uk>
Organization: Comp Sci, RMIT, Melbourne, Australia
Lines: 38

In article <3739@skye.ed.ac.uk>, richard@aiai.ed.ac.uk (Richard Tobin) writes:
> Are there *any* widely-used processors
> that can't implement alloca() reasonably efficiently even with
> compiler support?

Any processor that can't implement alloca() as a built-in operation is
going to have a hard time with PL/I, Fortran 90, and Ada, all of which
allow the declaration of local variables whose size is not known until
the declaration is elaborated.  The fact that gcc supports alloca() as
well as "auto int foo[some_expr()]" is not a coincidence.

There is, by the way, a compromise position, which was provided in BCPL.
BCPL didn't have alloca(), but it did have 

	APTOVEC(function, size_of_memory_block)		// argument order?

The equivalent in C could almost be implemented as

	int aptovec(int (*fn)(void *), size_t amount)
	    {
		void *space = malloc(amount);
		int result = space ? fn(space) : -1;
		free(space);
		return result;
	    }

except that the memory is supposed to go away automatically on longjmp
as well as exit.  On the machines I know where alloca() is hard to do
as a normal function, aptovec() can be done quite easily in assembly code
with no special compiler support.  (Which is not to assert that this is
true on _all_ machines.  I don't _know_ all machines.)

The problem with people re-inventing the wheel (aptovec) is that
they tend to invent triangular ones (alloca).

-- 
The problem about real life is that moving one's knight to QB3
may always be replied to with a lob across the net.  --Alasdair Macintyre.