Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!ames!uhccux!munnari.oz.au!cs.mu.oz.au!ok
From: ok@cs.mu.oz.au (Richard O'Keefe)
Newsgroups: comp.lang.c
Subject: Re: effect of free()
Message-ID: <2118@munnari.oz.au>
Date: 16 Sep 89 06:31:45 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <33383@ism780c.isc.com>
Sender: news@cs.mu.oz.au
Lines: 38

In article <33383@ism780c.isc.com>, news@ism780c.isc.com (News system) writes:
> I don't understand this discussion.  Inspecting a pointer variable that is
> not initialzed is no different from inspecting ANY uninitialized variable.  A
> pointer that has free applied to it is unitialized.  How in the world could
> any programming language be defined to assign a useful meaning to the
> inspection uninitialized data?  Hint: defining the state of local data at
> procedure entry can be very expensive.
> 
>     Marv Rubinstein

The context of the discussion is
	p = NULL;
	...
	if (hairy-test-expression) {
	    ...
	    p = malloc(some_size);
	    assert(p != NULL);
	    ...
	    free(p);
	    ...
	}
	if (p != NULL) ...   <- may go BANG! here.

Look at it carefully:  p is NOT "uninitialised".  Whether program execution
took the "p = malloc()" path or just fell straight through, p has in fact
been initialised to a meaningful value.  free() does not have any access to
p, only to the value of p.  There may be fifteen million variables all with
the same value as p; free() has no access to them either.  Hint: locating
all the variables with the same value as p and making them uninitialised
can be very expensive.

It appears that the draft standard DOES allow the program to do anything
the implementor pleases at the marked point, and that that was a careful
and deliberate choice based on the belief that there might be machines where
that might make sense (though not 680x0s, VAXen, /370s, 80*86s, or PR1MEs).
However, this has nothing to do with uninitialised variables.

The longer I use C, the better I like Ada, and I started out _hating_ Ada.