with_addr is basically that, but with a name and some documentation: https://doc.rust-lang.org/std/primitive.pointer.html#method.with_addr https://doc.rust-lan

with_addr is basically that, but with a name and some documentation: https://doc.rust-lang.org/std/primitive.pointer.html#method.with_addr https://doc.rust-lang.org/std/primitive.pointer.html#method.... As I understand it, Rust added this in part for experiments with CHERI but mostly for miri. Interestingly, the implementation of with_addr is very similar to your code. How do you handle cases where there are multiple possible sources of the capability? For example: int *a = …, *b = …; (int*)(((uintptr_t)a + (uintptr_t)b) << 2) I’m not sure I would allow this into any code I maintain, but still. There’s also the classic xor-list, and someone has probably done it like: struct node { struct node *p; }; struct node *next(struct node *here, struct node *prev) { return (struct node *)((uintptr_t)here ^ (uintptr_t)prev); } And this needs to either result in a compiler error or generate some kind of code. Rust’s with_addr wins points for being explicit and unambiguous. It obviously loses points for not being C. And Rust benefits here from all of this being in the standard library and from some of the widely-available tooling (miri) getting mad if code doesn’t use it. I can imagine a future Fil-Rust project doing essentially the same thing as Fil-C except starting with Rust code. It might be interesting to see how the GC part would interact with the rest of the language.