Path: utzoo!utgpu!attcan!uunet!husc6!uwvax!umn-d-ub!umn-cs!ns!ddb
From: ddb@ns.UUCP (David Dyer-Bennet)
Newsgroups: comp.lang.c
Subject: Re: alloca wars
Summary: Explicit free ruins whole idea
Keywords: alloca memory allocation architectures
Message-ID: <696@ns.UUCP>
Date: 3 Aug 88 18:28:13 GMT
References: <3950010@eecs.nwu.edu> <62170@sun.uucp> <62363@sun.uucp> <5422@june.cs.washington.edu>
Organization: Network Systems Corp. Mpls MN
Lines: 26

In article <5422@june.cs.washington.edu>, pardo@june.cs.washington.edu (David Keppel) writes:
$ 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?

   Well, the reasons why alloca is difficult to implement seem convincing.
However, the only point I ever saw to alloca was the automatic deallocation
on exit.  If you don't have that, what advantage is there over malloc or
any of the standard allocation routines?
-- 
	-- David Dyer-Bennet
	...!{rutgers!dayton | amdahl!ems | uunet!rosevax}!umn-cs!ns!ddb
	ddb@Lynx.MN.Org, ...{amdahl,hpda}!bungia!viper!ddb
	Fidonet 1:282/341.0, (612) 721-8967 hst/2400/1200/300