libpw.a

Root Boy Jim rbj at dsys.icst.nbs.gov
Wed Apr 19 03:36:53 AEST 1989


? From: Gordon Burditt <gordon at sneaky.uucp>

? There is an even better reason not to use alloca().  

? I claim that there exists NO correct implementation of alloca() (in any
? released or unreleased version of anything) under these conditions:
? 	(1) Alloca is implemented using the stack. (not malloc() and some
? 	    mechanism to keep track of what to free when), AND
? 	(2) The calling sequence is caller-pops-args, not callee-pops-args.
? 	    AND, 
? 	(3) The compiler doesn't implement alloca() as a built-in function
? 	    (as opposed to only a function stuck in a library without special
? 	    compiler knowledge of alloca(), which is hopeless).

? If you don't do (1), you are defeating the supposed advantages of alloca -
? speed, and either you have to do explicit freeing of memory somehow, or
? you might run out of memory sometime when you shouldn't.

Whereby you just call alloca(0) and if there is anything to clean up,
you get it back. If you supply Doug Gwyn's alloca.c, you allow less
capable machines to run the alloca infested code, albeit slower.

? Most systems that don't do (2) have problems with old code because
? you have to actually follow the rules for varargs or stdargs to do
? variable-argument functions, or they break.  You also need an
? instruction for "return and adjust stack".  GCC has it as an option
? for the 68010, and the Vax can use it.  Most compilers for various micros
? seem to use caller-pops-args.

I don't see the problem. Use the frame pointer.

? GCC implements alloca() as a built-in (assuming appropriate definitions
? in a header file), but still gets it wrong.  The main problem here
? is that it is necessary to evaluate ALL arguments that involve alloca
? to a multi-argument function before pushing ANY of them.  

? Before anyone starts yelling, "but mine works", try coming up with how the
? compiler is going to lay out the stack, considering function args and
? alloca-allocated memory, for the following code fragment....

? 	*(control = alloca(sizeof bar)) = initfunc( alloca(sizeof(struct foo1)),
? 		alloca(sizeof(struct foo2)), alloca(sizeof(struct foo3)),
? 		alloca(sizeof(struct foo4)), alloca(sizeof(struct foo5)) );

? Note:  "...." means code has been left out; it is NOT a misspelling for
? a character sequence used in declaring ANSI varadic functions.

Your code is meaningless. Alloca cannot be called in argument lists
for the exact reasons you specify.

? Even if you do make the compiler know about alloca(), and rule that you
? can't use a pointer to alloca in a pointer-to-function to make function
? calls, the code can still get very messy and slow.

? If the compiler references auto variables as an offset from the stack
? pointer (rather than a frame pointer), all bets are off.  If the compiler
? doesn't implement alloca as a built-in, you haven't a prayer of making
? even the simple cases work by writing a library function.

Alloca is a special purpose beast. No reason to try and make it general.

? 				Gordon L. Burditt
? 				...!texbell!sneaky!gordon

	Root Boy Jim is what I am
	Are you what you are or what?



More information about the Comp.unix.wizards mailing list