pointer representation (was: Re: effect of free())

[Richard O'Keefe]

In article <29171 at news.Think.COM>, barmar at think.COM (Barry Margolin) writes:
> In article <2075 at munnari.oz.au> ok at cs.mu.oz.au (Richard O'Keefe) writes:
[deleted]

> If the optimizer for an architecture where pointers may compare equal
> but not be completely equivalent were to perform such a
> transformation, it would be a buggy optimizer.

Yes, it would.  But the compiler writer would have been _seduced_ into
that mistake by the standard.  People are encouraged to think of == as
testing for EQUALITY.  In dpANS C, it appears that == does *NOT* have
the properties of equality, and at the very least this needs to be said
clearly and explicitly in the Rationale.

By the way, proper mathematical terminology would be that the pointers
are EQUIVALENT (under ==) but not EQUAL (because they may not be
substituted freely for one another).  It is precisely this kind of
jumbling of words and ideas which I claim is likely to confuse compiler
writers.

> You appear to be
> assuming a system-independent optimizer; what you've done is point out
> why such a thing is not really a good idea.

I am _sick_ of people trying to guess what I am assuming; they are _always_
wrong.  (At least in this thread they have been.)  I wasn't assuming a
system-dependent optimizer at all.  The point is that it is a standard
technique described in most good compiler books to keep track of which
locations hold the "same" value and to use the "cheapest" location with
the desired value.  Anyone writing an optimising compiler for C who was
not on the committee and hasn't been reading this thread, whether he is
trying to out-do GCC or just generate code for the HAL Whizzbang 99 is likely
to make the natural assumption that because == is _called_ an "EQUALITY
operator" it has the properties of equality.  The more cunning of them may
be aware of some problems with floating-point "equality", but they are
likely to also be aware that Fortran and Ada compilers are licensed to act
_as if_ floating-point equality was exact.


The bottom line for those of us who do not write compilers is that we
should take care that two pointers are only compared when
EITHER (a) the two cannot refer to the same object
  OR   (b) the two must have been generated in the same way, so that they
	   cannot have different access rights &c
and that a pointer must not be referred to in any way after it has been
free()d.  Even ptr = NULL is too risky:  what if the compiler generates a
sequence which uses a read-modify-write cycle with the old value being
loaded into an address register?  -- remember how CLR works on a 68000...