4 ms·

Your deref function will fail, yeah. The pair of conversions is guaranreed to always produce a pointer with a capability. That’s how I implemented it and it’s

• amluto 2y ago
  How far can the pair of conversions be pushed? Will this work: (int*)(f((uintptr_t)p)) Does it matter if f is inline? Could someone implement Rust’s with_addr as: (int*)((uintptr_t)p, addr) FWIW, I kind of like zptrtable, and I think Fil-C sounds awesome. And I’m impressed that you were able to port large code bases with as few changes as it seems to have taken.
  • pizlonator 2y ago
    Your first example will hilariously work if `f` is inline and simple enough and optimizations are turned on. I'm not sure I like that, so I might change that. I'd like to only guarantee the you get a capability in cases where that guarantee holds regardless of optimization (and I could achieve that with some more compiler hacking). 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 I have a helper like that called `zmkptr` (it's just an inline function that does exactly the above).
    • amluto 2y ago
      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.
      • pizlonator 2y ago
        My compiler analysis says that if you have two possible pointers that a capability might come from, like in your first example, then you get no capability at all. I think that's a better semantics than picking some capability at random. If you want to be explicit about where the capability comes from, use `zmkptr`.