Path: utzoo!attcan!uunet!lll-winken!lll-tis!ames!mailrus!cornell!uw-beaver!uw-june!pardo
From: pardo@june.cs.washington.edu (David Keppel)
Newsgroups: comp.lang.c
Subject: alloca wars
Summary: change the semantics
Keywords: alloca memory allocation architectures
Message-ID: <5422@june.cs.washington.edu>
Date: 2 Aug 88 19:46:38 GMT
References: <3950010@eecs.nwu.edu> <62170@sun.uucp> <62363@sun.uucp> <8293@smoke.ARPA> <19895@cornell.UUCP>
Reply-To: pardo@june.cs.washington.edu (David Keppel)
Organization: U of Washington, Computer Science, Seattle
Lines: 42

>[ When is it hard to do alloca? ]

The fast (compiler-supported) alloca may turn off other optmizations.
It need only turn them off in the function using alloca and (given
that memory management is often expensive) you aren't likely to lose a
whole lot by using alloca.

The slower (library-supported) alloca will break whenever you have a
multi-thread (e.g., lightweight process) program (at least in every
"reasonable" implementation that I've thought of).  This may be a
problem for shared-memory multiprocessors.

During the last alloca war somebody suggested having alloca require
explicit "free" semantics, so that malloc-based (library) allocations
would be reasonable to write and work on shared-memory multiprocesors.
This would probably also hose fewer compilers/architectures.  If I
understand, code would look like:

	:
	foo = alloca( size );
	:
	afree( size );
	return( value );

This complicates the code slightly, but (I believe) would give
everybody "the best of both worlds".  Does anybody object to these
semantics?

Note that GNU products are *not* designed to work on every machine.
The documentation for gcc (as I remember) says that it is designed to
work with 32-bit machines with a flat (non-segment-register) address
space.  Alloca could be seen as a constraint on this.  Finally, gcc
makes some extensions that can destroy alloca semantics; garbage
collection can (silently) take place before the end of the function,
so even their use is broke (and is documented as such).

[ Please, he said following up, try to keep down your
  followup-rate.  We just got done with this war a few weeks ago ]

	    ;-D on  ( What, me deallocate? )  Pardo

		    pardo@cs.washington.edu
    {rutgers,cornell,ucsd,ubc-cs,tektronix}!uw-beaver!june!pardo