alloca() portability

[Chris Torek]

In article <27634 at mimsy.umd.edu> I wrote:
>>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).
  [example deleted]

In article <656 at metaware.metaware.com> fjb at metaware.metaware.com
(Fred Bourgeois) writes:
>Oh come on!  You can't claim this as a problem with alloca!  The standard
>clearly states (Appendix F.1) that "the order in which side-effects take
>place" is unspecified.  And clearly, alloca has a side effect - it modifies
>the (possibly virtual) stack pointer.  Also consider 3.3.2.2, the order of
>evaluation of arguments to a function is unspecified.
 [different example deleted]
>This is just another area in which the programmer must be aware of a subtlety
>in the language.

But this is just the point---alloca is NOT IN THE LANGUAGE!

You say that alloca `modifies the ... stack pointer'.  Not only might there
be no stack *pointer*, but there may even be no *stack*.  My example was
a transformation of the form

	unaliased_local_var_1 = function_1();
	function_2(unaliased_local_var_1, unaliased_local_var_2);

becomes

	function_2(function_1(), unaliased_local_var_2);

By translating the ANSI C standard into formal specifications, I claim
I can prove that this transformation is correct.  And it *is* correct,
for every correctly-implemented function *except* alloca().  (It can fail
on improperly implemented functions, e.g., if function_1 were

	char *foo(int n) {
		char buf[20];
		(void) sprintf(buf, "%d", n);
		return buf;
	}

then this particular transformation might cause different local memory
allocation patterns and cause the returned buffer to be overwritten earlier).

Anyway, we have seen testimony from various people (including the author
of the Zortech C compiler) that it is not possible to optimize correctly
when `alloca' is used, unless you have the source to the compiler.

>I agree, the standard should specify a method for allocating local space.
>Given good compiler support for alloca, and programmer awareness of the
>pitfalls (e.g. side-effects are not portable, etc.), alloca is an adequate
>solution *for the time being*.  In my opinion, it should eventually be made
>a part of the standard, because it is also the fastest way to allocate local
>memory.

This is a different argument: `we need this functionality, and we think
this is the right way to provide it', as opposed to `this is the way to
do it'.  If you want to argue for alloca support in compilers, and want
people to use alloca (at the risk of having their code fail, apparently
at random, when they use compilers without such support), that is fine
with me---as long as you warn them.
-- 
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