Not a big fan of this line of thinking since if you tried to deploy a C implementation that just implements what's in the C standard, then you'd quickly find that real world C code expects more of pointers than the C standard promises.
Fil-C supports a superset of the C standard but a subset of what contemporary mainstream C compilers support (you can't pass an integer around in memory that is really being used to represent a pointer in Fil-C, but you can in Yolo-C).
You just can’t cast a pointer to uintptr_t, then store that int into memory, then load it back, then cast it back to pointer, and then dereference that pointer.
I just don’t let integer types carry capabilities. If I did, things would get weird (like if you said `x + y` and both happened to carry capabilities then what would you get?)
Fil-C supports a superset of the C standard but a subset of what contemporary mainstream C compilers support (you can't pass an integer around in memory that is really being used to represent a pointer in Fil-C, but you can in Yolo-C).