I found this while looking for a solution for more easily removing some unsafe code from a library that does a lot of C FFI. I didn't end up going with it though, for now I'm taking an approach of mapping valid pointers that I return to the caller and then validating that pointers passed to my library functions are in that valid mapping (and then also using that valid mapping to contain some additional information that doesn't fit in the ABI of the structs that the pointers are for that I use to safely do validation. So e.g., I can store the range of some other valid member pointers as a normal safe rust reference and then index into it with member pointers on the struct, completely avoiding unsafe code despite having this FFI boundary (obviously the FFI boundary itself is still unsafe, but I can take this ugly C struct with a bunch of raw pointers and handle it safely)).
I found this while looking for a solution for more easily removing some unsafe code from a library that does a lot of C FFI. I didn't end up going with it though, for now I'm taking an approach of mapping valid pointers that I return to the caller and then validating that pointers passed to my library functions are in that valid mapping (and then also using that valid mapping to contain some additional information that doesn't fit in the ABI of the structs that the pointers are for that I use to safely do validation. So e.g., I can store the range of some other valid member pointers as a normal safe rust reference and then index into it with member pointers on the struct, completely avoiding unsafe code despite having this FFI boundary (obviously the FFI boundary itself is still unsafe, but I can take this ugly C struct with a bunch of raw pointers and handle it safely)).