That's not true. `usize` and `isize` are explicitly specified to roundtrip a pointer address. You are correct that this would imply they need to be 128-bit in CHERI which will be a major perf hit, and this is actually blocking Rust support on CHERI, and the solution might be to change the guarantees (but it is hard because code in the wild relies on it), but it is the current guarantee.
I think what's going on is that you've half understood the situation with CHERI as of a few years ago and now you're trying to explain your half-understanding to me confidently as if you're correcting me.
As I said, these types are the same width as an address on the target but a CHERI pointer isn't just an address, that's why they are so wide.
No, I usually follow language and opsem discussions. While CHERI discussions are not something I follow closely, unless you have an explicit link I'm pretty sure I didn't miss something that important.
The strict provenance APIs or the "Rust has provenance" RFC are not relevant here (more precisely, they help clarify the options but do not solve the problem).
> Pointers to sized types have the same size and alignment as `usize`.
Which just cannot be guaranteed on CHERI with 64-bit `usize`.
There are discussions like there were before, and it's pretty clear that we'll have to give up either performance or possibly quite a lot of compatibility, but no decision.
As I said, these types are the same width as an address on the target but a CHERI pointer isn't just an address, that's why they are so wide.
Maybe start here: https://doc.rust-lang.org/std/ptr/index.html#strict-provenan...
The strict provenance APIs or the "Rust has provenance" RFC are not relevant here (more precisely, they help clarify the options but do not solve the problem).
The problematic statement is still in The Reference (https://doc.rust-lang.org/reference/type-layout.html):
> Pointers to sized types have the same size and alignment as `usize`.
Which just cannot be guaranteed on CHERI with 64-bit `usize`.
There are discussions like there were before, and it's pretty clear that we'll have to give up either performance or possibly quite a lot of compatibility, but no decision.