Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!metaware!fjb
From: fjb@metaware.metaware.com (Fred Bourgeois)
Newsgroups: comp.lang.c
Subject: Re: alloca() portability
Summary: ANSI XJ311/90-013 3.3, 3.3.2.2
Keywords: argument evaluation
Message-ID: <656@metaware.metaware.com>
Date: 16 Nov 90 18:12:52 GMT
References: <14377@smoke.brl.mil> <9122@ncar.ucar.edu> <27537@mimsy.umd.edu> <PAULB.90Nov12131357@hcx2.ssd.csd.harris.com> <s64421.658490039@zeus> <27634@mimsy.umd.edu>
Reply-To: fjb@metaware.UUCP (Fred Bourgeois)
Followup-To: comp.lang.c
Organization: MetaWare Inc., Santa Cruz, CA
Lines: 62
Expires:
Sender:
Distribution:

In article <27634@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>In article <PAULB.90Nov12131357@hcx2.ssd.csd.harris.com>
>paulb@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:

Clean or not clean, it is the fastest way to allocate memory needed only for
the lifetime of the current routine.  Assuming your compiler implements it
properly.  If you're not sure, use the `#define alloca malloc' method.

>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
    [example deleted]
>on fifty different architectures or so, and count success to failure
>ratios.  You may have to compile the first without any optimisation.)

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.  Try the following on
fifty different architectures and see what results you get:
	#include <stdio.h>
	/* insert your favorite push/pop functions */
	extern int push(int s); /* push returns argument pushed */
	extern int pop(void);
	int main() {
	#if defined OPT
	    printf("stack(%d %d)\n", push(23), pop());
	#else
	    int a = push(23);
	    printf("stack(%d %d)\n", a, pop());
	#endif
	    }
This is just another area in which the programmer must be aware of a subtlety
in the language.

>In article <s64421.658490039@zeus> s64421@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.%
[stuff deleted]

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.

---
Fred Bourgeois, MetaWare Inc., 2161 Delaware Avenue, Santa Cruz, CA 95060-2806
fjb@metaware.com                                        ...!uunet!metaware!fjb
	     Colorless Green Ideas Sleep Furiously, and so do I.