Esthetics (or worse?) of Secure Pointers

[John Gilmore]

> John  eventually convinced me that there's no way to decide
> at compile time what a subfunction's boundedness is. Bummer.
> This led us to the compile-the-whole-thing approach, which
> we all find scary. Hence, this request for more brain cells.

I don't find it scary at all, I find it the obvious thing to do.

The whole idea, from my point of view, is to implement secure pointers
efficiently enough that people just accept the 10-15% overhead, since
for most people CPU cycles are close to free anyway.  And eventually
to influence chip architecture for more efficient support.  I see little
point in implementing a curiosity that nobody will use; if it doesn't
have a shot to become the mainstream, then it isn't worth doing.

With these goals for the project, it makes no sense to waste any
effort trying for backward calling sequence compatability.  It would
be like trying to make x86 code be able to call ARM code or SPARC
code.  Yes, you could work very hard to make that happen (like Apple
did for intermixing 68000 and PowerPC code by emulation).  You could
mangle the debugger, the compiler, the linker, the runtimes, all in
pursuit of this crazy goal.  But why would you bother?

	John

PS:  One place where you could build calling sequence translators
is on the Unix system call boundary between kernel and user space.  That
work has already been done, so you could run a secure-pointers application
on an insecure-pointers kernel, or vice verse.  Handily, the system calls
all take length parameters, so you can calculate good bounds if you need to.