Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!cs.utexas.edu!uunet!yale!bunker!garys
From: garys@bunker.UUCP (Gary M. Samuelson)
Newsgroups: comp.lang.c
Subject: Re: The free() thing
Message-ID: <7513@bunker.UUCP>
Date: 15 Sep 89 21:10:56 GMT
References: <1989Sep14.022055.5961@twwells.com>
Reply-To: garys@bunker.UUCP (Gary M. Samuelson)
Organization: ISC-Bunker Ramo, an Olivetti Company, Shelton, Ct
Lines: 42

In article <1989Sep14.022055.5961@twwells.com> bill@twwells.com (T. William Wells) writes:
>I posted a note on using a pointer after it was freed that seems to
>have become lost. The point is that *any* dpANS compliant compiler,
>on any system, may generate invalid code if you use a pointer after
>it is freed. Here is how:
>
>Free() is defined in the dpANS library. That being the case, the
>compiler is free to assume that the pointer's value is not being used
>legitimately after the call. It knows that the object to which the
>pointer pointed no longer exists, so there is no valid use of the
>pointer's value.

I disagree.  For purposes of debugging, I have written my own
functions to call malloc() and free().  Mymalloc() calls malloc()
and records the pointer returned.  Myfree() checks to make sure that
(1). the pointer I want to free() was one originally obtained by
mymalloc(), and (2) that it has not already been released by myfree().
I claim that this is a valid use for a pointer which no longer points
to anything.

>During code generation, it could mark the location the pointer is
>stored in as dead right after the pointer's value is made available
>for the free call, since it knows that there can be no legitimate
>reason to access the value of the pointer.

No compiler has any business changing the value of a variable
I have declared, except when I have written code to do so.
But even so, suppose there was another copy of that same pointer
in another variable?  How will the compiler know about that one?

>So if you want to write portable programs, you had better assume that
>a freed pointer has no value that you should look at. Because it may
>have no determinate value.

Notice to compiler vendors:
No compiler I want to buy or use is going to exhibit this behavior.
If I want to examine a pointer, I better be able to.

As someone else has said, some day there will be two kinds of C
compiler: standard-conforming, and useful.

Gary Samuelson