Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!iuvax!cica!tut.cis.ohio-state.edu!cs.utexas.edu!samsung!xylogics!merk!spdcc!ima!haddock!karl
From: karl@haddock.ima.isc.com (Karl Heuer)
Newsgroups: comp.lang.c
Subject: Re: Function returning Structure:  How does it work?
Keywords: structure, struct
Message-ID: <16754@haddock.ima.isc.com>
Date: 31 May 90 01:20:49 GMT
References: <1990May28.215331.29333@agate.berkeley.edu> <18222@well.sf.ca.us> <8048@crdgw1.crd.ge.com>
Reply-To: karl@haddock.ima.isc.com (Karl Heuer)
Distribution: usa
Organization: Interactive Systems, Cambridge, MA 02138-5302
Lines: 23

In article <8048@crdgw1.crd.ge.com> larocque@jupiter.crd.ge.com (David M. LaRocque) writes:
>I think I must be missing something fundamental in the way
>storage allocation works.  I see how malloc() can return 
>"permanant" storage in memory that the caller knows won't
>get overwritten until free() is called, at least I think I 
>understand the K&R II description of their malloc routine (pg 185).
>However, in the above approach, how can a caller be sure that
>makepoint() returned memory that won't get trounced somehow?

The usual implementation is that the caller supplies the storage space.

>In addition if a point is no longer needed is there a method
>analagous to free() that can be used to return the point's
>memory to the operating system?

No need.  The caller knows when it's done with it (usually by the end of the
next operator).  Note that in
	struct point p;
	p = make_point(x, y);
the contents are being copied, not the address, so the temporary storage may
be reclaimed immediately afterwards (regardless of the lifetime of `p').

Karl W. Z. Heuer (karl@ima.ima.isc.com or harvard!ima!karl), The Walking Lint