Here and here we mention segregating capabilities into their own parts of memory, at least by units as large as pages. The C programming language delivers the struct construct which packages several values into one value. Among these several values may be pointers which allow friendly code to find data in a graph of such struct’s. There is a vast body of software that uses this pattern. Is there hope of preserving this software in the new world where a struct that includes a pointer works as it did before when that pointer is a capability? I think it a stretch but here is one path which follows my preferred plan of segregating capabilities.

Today a struct is presumed to be a value built by ‘concatenating’ the bits of the constituent values. If one of the constituent values is a capability we are in a bind. The hack proposed here is to compose some structs, those whose constituent values include a capability, of capabilities instead. This means coding the data constituents of the struct as capabilities. Keykos specifically provides number keys which hold 11 pure data bytes at a physical cost of 12 or 16 bytes. The CPU cycles to turn such coded data into real data is many cycles in any of the real implementations of Keykos. It would be much less in case of a hardware implementation of Keykos. A savvy compiler could decide at compile time for each struct definition that it encounters upon one of three implementation techniques for values of that struct:

Pure data
This is chosen when constituent values are all data. If it is necessary at allocate storage for this struct it is in data memory.
A little or no data and many caps
The data can be coded as caps and the whole struct composed of caps. Any storage allocated to these values is in cap storage.
A few caps and much data
Here the struct must straddle the boundary. The value is composed of two parts with the parts being connected magically by compiler logic or there being a data capability in the cap part to the data part. If storage is allocated the address is that of the cap portion, and that portion includes a cap to the data portion.
The distinction between a cap to cap storage and a cap to data storage is already an integral part of any capability to storage.

This proposal impinges on semantics of memcpy. An upgraded version of memcpy might notice that it is copying a block in cap memory. In that case must it be aware of data portions located by pointer (that it is copying) and copy those data too? In short does it make a deep copy or shallow copy.

I don’t hold out much hope for a smooth transition of non-capability savvy software in this scheme.

The above is vague on how much modification of the source is necessary. Are we trying to make C into a type safe language?