I’m glad Phil’s work is finally getting the recognition it deserves.

There may be useful takeaways here for Rust’s “unsafe” mode - particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

▲

gpm 4 days ago | parent [-]

> particularly for applications willing to accept the extra burden of statically linking Fil-C-compiled dependencies. Best of both worlds!

As near as I can tell Fil-C doesn't support this, or any other sort of FFI, at all. Nor am I sure FFI would even make sense, it seems like an approach that has to take over the entire program so that it can track pointer provenance.

	▲	hedgehog 4 days ago \| parent \| next [-]
		For securing and maintaining a complex legacy application it seems like a reasonable approach would be to move the majority into Fil-C, then hook the bits that don't fit up via RPC. Maybe some bits get formal verification, rewritten in Rust, ported to new platform APIs, whatever, but at least you get some safety for the whole app without a rewrite.
	▲	quotemstr 4 days ago \| parent \| prev [-]
		He could add an API to mint a capability out of thin air. It could even be done out of process. In fact, I think Fil-C and CHERI could implement 90% the same programmer-level API!