Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!haven!mimsy!chris
From: chris@mimsy.umd.edu (Chris Torek)
Newsgroups: comp.lang.c
Subject: Re: Life after free?
Keywords: free malloc
Message-ID: <26770@mimsy.umd.edu>
Date: 29 Sep 90 06:58:00 GMT
References: <quan.654410256@sol> <5620@stpstn.UUCP>
Distribution: comp
Organization: U of Maryland, Dept. of Computer Science, Coll. Pk., MD 20742
Lines: 48

>In article <quan.654410256@sol> quan@sol.surv.utas.oz (Stephen Quan) writes:
>>Any comments on free-ing tmp before it is return-ed?

In article <5620@stpstn.UUCP> lerman@stpstn.UUCP (Ken Lerman) writes:
>Not only is it sensible, the semantics of free require it.

Nay, not so.

>So, yeah, it could be used.  Is it useful (in the sense of full of
>use)? No way.

Aye.

To sum up: in many implementations, the space released via free()
remains unchanged at least until a later call to malloc or calloc.
A few even document this behaviour.  It is, however, not guaranteed
by the closest thing we have to a standard (i.e., ANSI X3.159-1989,
a.k.a. `ANSI C'), and there are some implementations out there that
will in fact immediately stomp on the space released by free().

As to the other question---that of returning the value of an automatic
---I think it has been sufficiently answered, but just for the record,
there is nothing wrong with returning the value of an automatic `char *'
variable:

	char *f() {
		char *p;
		int g();
		p = g() ? "yes" : "no";
		return p;
	}

This is no worse than, e.g.,

	int f1() {
		int i;
		i = g() ? 1 : 0;
		return i;
	}

The value is not necessarily returned in a register: all you can be
sure of is that the value is returned.  The compiler is free to, as
Ron Natalie once put it, stuff arguments into an envelope and mail
them off to the function being called, and results can be returned
the same way.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 405 2750)
Domain:	chris@cs.umd.edu	Path:	uunet!mimsy!chris