The free() thing

[T. William Wells]

In article <7513 at bunker.UUCP> garys at bunker.UUCP (Gary M. Samuelson) writes:
: In article <1989Sep14.022055.5961 at twwells.com> bill at 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.

So what? The standard defines what constitutes validity. And *it*
says that, once you've freed the pointer, if you do anything with it,
the results are undefined. You *may* get away with it, on some
implementation, or with some particular combination of compiler
flags. Or you may not. But whatever, it is always "getting away with".
It should not be presumed to be portable.

: >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.

Baloney. The compiler may do whatever is not inconsistent with the
language specification. Many compilers already change variables
behind your back. For example, there are compilers that determine
when a variable is no longer in use and, if there s another variable
that can use the same memory, will make them share the same location;
change the second variable and you change the first. My example with
free() is just another way the compiler vendor might do this.

: But even so, suppose there was another copy of that same pointer
: in another variable?  How will the compiler know about that one?

It won't likely. Which increases the probability of your getting away
with using it, though it does not make it unity. The compiler vendor
is not obligated to prevent you from doing something stupid.

: >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.

Notice to compiler vendors:
I will judge compilers on compliance to the standard first, and
quality of implementation second. Speed is an important consideration
and, since *I* won't do stupid things like look at pointers when I'm
not supposed to, go ahead and trash freed pointers. Now, I'll admit
that I'd like a compiler option that turns off this optimization, but
I won't insist.

---
Bill                    { uunet | novavax | ankh | sunvice } !twwells!bill
bill at twwells.com