Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!cs.utexas.edu!sun-barr!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: pointer representation (was: Re: effect of free())
Message-ID: <2075@munnari.oz.au>
Date: 11 Sep 89 02:19:31 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <11021@smoke.BRL.MIL>
Sender: news@cs.mu.oz.au
Lines: 57

[This thread is about the effect of the "pointers are equal if and only
if they refer to the same object" rule on systems with ring numbers in
hardware addresses.]

Doug Gwyn wrote:
> Your original concern was with OS kernels trying to
> rely on the ring number extracted from a C pointer.  If the OS kernel
> needs to deal with the ring number, it needs to do the bookkeeping some
> other way.  Your example is essentially
> 	struct mach_addr { ... ring; ... loc; } x, y;
> 	if ( x.loc == y.loc )
> 		operation_on( y.ring, y.loc );
> 		/* where operation_on( x.ring, x.loc ) was intended */
> When spelled out in detail, it looks more like the bug that it is.

That doesn't look _quite_ like what I had in mind.  Here's an example
which I did have in mind:

	int store_for_user(int *p, int i)
	    {
		extern int *q;

		return p == q ? *p = i, 1 : 0;
	    }

where q is a pointer which has been created by kernel code (and thus has
ring number 0) while p is a pointer which has been passed by user code
(and thus has ring number 3).  The point is that on a machine with ring
numbers (or any other access right mechanism) encoded into machine
addresses, p and q can point to the same object without having the same
access rights to it.  If pointer equality ignores those access rights,
then pointer comparison on such machines (a) must be expensive and typically
can't be done using address registers and (b) has the bizarre property that
equality does not entail equivalence.  My point is that optimising compilers
generally assume that "equals may be subsituted for equals" (that's what
equality is all about), so that *correct* source code is very likely to be
incorrectly *optimised*.  For example, a compiler might translate my
store_for_user() example as if the return statement were

		return p == q ? *q = i : 0;

(q is not declared 'volatile').  It's not a question of allowing badly-
written programs to work; the programmer may have been quite careful about
which of several apparently equal pointers was used.  The point is that an
assumption which *is* true of numbers is true of pointers on a great many
machines, but under the pANS interpretation of "equality" it is not true,
so that there is a serious risk of compiler-writers getting it wrong.  At
the very least this needs to be spelled out in unmistakeable detail in
the Rationale so that compiler writers have no excuse for missing it.

Doug Gwyn wrote:
> I don't think the difficulty of a ring-supporting OS implementation is
> a very strong argument for imposing additional constraints on C pointer
> implementation.

Tu quoque: I don't think the difficulty of a loads-into-address-registers-
may-trap implementation is a very strong argument either.