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

[Doug Gwyn]

In article <2064 at munnari.oz.au> ok at cs.mu.oz.au (Richard O'Keefe) writes:
>... I assume that x == y in C means "x and y point to the same place".
>1.  Does the current draft actually say this?

What it says is that (apart from null pointers) pointers that compare
equal refer to the same object (or function) and pointers that refer
to the same object (ditto) compare equal.

>If that is so, then a C compiler which exploits x == y to use y where x
>was written is _not_ guaranteed to preserve things like a ring number,
>which could be Bad News for people trying to write operating system
>kernels in C.

If they're trying to represent (address+ring) as a C pointer, they're
ALREADY in trouble!

>2.  According to the current draft, are C compilers allowed to use
>    y instead of x if x == y and it is known that x and y cannot have
>    changed since that was established?

Compilers can optimize however they want so long as the observable
results (apart from timing considerations and other side-effects not
within the scope of the Standard) are as though produced by the
abstract C machine operating as specified in the Standard .

>If, in order to avoid the problem of misteriously losing access rights,
>getting pointers with the invalid bit on, and so on, compiler writers
>adopt the "same pointer" semantics rather than the "same place" semantics,
>the argument for doing pointer comparison in address registers goes away.

So does speed of computation on many systems, where the natural way
to do pointer arithmetic can produce several different representations
for the same pointer.  By limiting the need for "normalization" to
just the comparison of pointers, considerable overhead is avoided.

What you're calling "same pointer" is actually "same representation".
So far as C is concerned "same pointer" means: both null or both
refer to the same object or both refer to the same function.
Details of representation are left up to the implementor.