The pair of conversions is guaranreed to always produce a pointer with a capability. That’s how I implemented it and it’s low-tech enough that it could be specified.

    (int*)(f((uintptr_t)p))

Could someone implement Rust’s with_addr as:

    (int*)((uintptr_t)p, addr)

Not sure about the semantics of with_addr. But note that you can do this in Fil-C:

    char* p = ...;
    uintptr_t i = ...;
    p -= (uintptr_t)p; // now p is NULL but still has its original capability
    p += i; // now p points to whatever i's address was, but has p's original capability

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)

    struct node { struct node *p; };
    
    struct node *next(struct node *here, struct node *prev)
    {
        return (struct node *)((uintptr_t)here ^ (uintptr_t)prev);
    }

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.

If you want to be explicit about where the capability comes from, use `zmkptr`.