Representation of unions on capability machines

Barry Margolin barmar at think.COM
Sat Sep 16 06:12:41 AEST 1989


Jeff Rosenfeld's (jdr+ at andrew.cmi.edu) posting in the "effect of
free()" chain got me to thinking about how unions containing pointers
and non-pointers would be implemented on a particular class of
machine.  The class of machines I'm wondering about are capability
machines.  On many of these machines, pointers are actually
capabilities; the access rights that a process has to some data is
encoded in the capability word.  A consequence of this is that
capabilities may only be created by secure code, although they
generally can be copied by user code; if user-mode code could create a
capability, it could fill in whatever address and access rights it
wanted and thus bypass the system security mechanism.  The hardware
implementation of this is usually a tagged memory, where the tag
indicates whether the word contains a capability or data; data and
capabilities may only be read into address and data registers,
respectively, while storing a register sets the tag from the type of
register.  It might also be implemented by marking pages or segments
as being able to hold data or capabilities, and then the register type
must agree with the register type.

Without getting into debates over the reasonability of capability
architectures, I'd like to ask what the appropriate way to implement a
union like

union pi {
    char *ptr;
    unsigned long num;
} x;

is on a machine that has separate data and capability pages.  Does C
require that x.ptr and x.num actually occupy the same storage?  It
doesn't appear to require that assigning to one member actually affect
the other member, because it is invalid to reference the other member
after such an assignment (so how could you tell if it were affected?).
Does C require that &x.ptr == ((char *) *)&x.num?

Barry Margolin
Thinking Machines Corp.

barmar at think.com
{uunet,harvard}!think!barmar



More information about the Comp.lang.c mailing list