Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!uflorida!haven!adm!smoke!gwyn
From: gwyn@smoke.BRL.MIL (Doug Gwyn)
Newsgroups: comp.lang.c
Subject: Re: pointer representation (was: Re: effect of free())
Message-ID: <11021@smoke.BRL.MIL>
Date: 10 Sep 89 11:13:03 GMT
References: <319@cubmol.BIO.COLUMBIA.EDU> <3756@buengc.BU.EDU> <11016@smoke.BRL.MIL> <2072@munnari.oz.au>
Reply-To: gwyn@brl.arpa (Doug Gwyn)
Organization: Ballistic Research Lab (BRL), APG, MD.
Lines: 50

In article <2072@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>In article <11016@smoke.BRL.MIL>, gwyn@smoke.BRL.MIL (Doug Gwyn) writes:
>: In article <2064@munnari.oz.au> ok@cs.mu.oz.au (Richard O'Keefe) writes:
>: >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!
>I don't quite follow this.  On the PR1ME 50 series -- and some others --
>the native "address" format *always* has a ring number in it.  It's not
>a question of someone implementing C on such a machine _choosing_ to
>represent address+ring as a C pointer, it's a question of them choosing
>to represent C pointers as native hardware-type addresses, and those
>addresses always have ring numbers in them.

You're reading it backwards -- of course C pointers would be represented
using machine addresses, which in this case happen to have ring numbers
attached to them.  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.
The OS, in dealing with multiple active rings, has failed to check
whether the ring is appropriate, and if it were able to know that x.ring
was appropriate, it should also be able to retain the knowledge of what
x.ring happens to be and do the operation using that explicit ring
knowledge.  In fact a data structure similar to my "struct mach_addr"
may be desirable in such an OS implementation.

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.

Pointer implementation that ignores ring number in comparisons will
perhaps work for user processes, but the kernel would have to be more
careful.  (It's probably written in PL/I anyhow.  You think C is hard
to use for such an OS implementation...)

Almost any reasonable multi-tasking OS is going to have to keep
straight which context a given address value belongs to.  It hasn't
been a big problem in UNIX so far; one merely has functions for
facilitating data access "across the OS/user interface", or even
better in some implementations, uses remapping to temporarily share
a portion of address space.  Right off hand, I don't see how it would
be much worse on a ring-based machine.