Path: utzoo!utgpu!water!watmath!clyde!att!pacbell!ames!necntc!frog!john
From: john@frog.UUCP (John Woods)
Newsgroups: comp.unix.wizards
Subject: Re: back to the (ivory) tower
Keywords: compiler quality
Message-ID: <1121@X.UUCP>
Date: 9 Jun 88 03:55:00 GMT
References: <16018@brl-adm.ARPA>
Organization: Servants of the Great White Frog
Lines: 28

In article <16018@brl-adm.ARPA>, ted%nmsu.csnet@relay.cs.net writes:
> The 4.3 manual entry for alloca says:
>     BUGS
>          Alloca is both machine- and compiler-dependent; its  use  is
>          discouraged.
> On the other hand, alloca is often used and strongly supported by the
> gnu camp (n.b. heavy use in emacs and bison)....
> It is also true that alloca is almost trivial to implement on most
> machines (say with a macro which expands to a single machine
> instruction to in(de)crement the stack pointer).
> What is the opinion of the masses?  Is alloca really such a problem
> across differing architectures?  Is it really that useful?

Architecture is not the only problem, as the manual entry hints; many
compilers make alloca() impossible to use.  What's more, it's GOOD that they
do so:  many optimizing compilers pull stunts with the stack like not
resetting the stack pointer after each function call, so as to save time.
Others dispense with a frame pointer entirely, because they "know" where the
stack pointer will be in relation to the hypothetical frame pointer, and just
index off of it appropriately.  Some even do both.  Slowing down every single
program just so a couple of programs can be written without paying attention
doesn't seem the best of tradeoffs.
-- 
John Woods, Charles River Data Systems, Framingham MA, (617) 626-1101
...!decvax!frog!john, john@frog.UUCP, ...!mit-eddie!jfw, jfw@eddie.mit.edu

No amount of "Scotch-Guard" can repel the ugly stains left by REALITY...
		- Griffy