This would also mean that you wouldn't need unsafe{} to call into the Fil-C ffi. The majority of unsafe{} in (non pure-rust) cargo dependencies is calling C ffi. Rust + Fil-C is a great match that fills a particular niche, I'd love to see it happen.
This would also mean that you wouldn't need unsafe{} to call into the Fil-C ffi. The majority of unsafe{} in (non pure-rust) cargo dependencies is calling C ffi. Rust + Fil-C is a great match that fills a particular niche, I'd love to see it happen.
How does it prevent multiple mutable pointers?
Multiple mutable pointers are fine. You need to be careful to ensure you don't turn them into multiple coexisting mutable references, though.
Nice pedantry. How does it prevent multiple coexisting mutable references?
It’s not pedantry. Pointers and references are truly different things.
A normal C compiler actually has to worry about a lot of extreme cases.
Imagine a function takes two pointer arguments. What if they point to the same thing? What if one points to the other and is used for a write?
The nature of the code generated varies greatly if these are possibilities…
I'm not sure you need to? Rust references don't exist in C, after all.
That being said I wouldn't be surprised if there were other factors that would weigh against considering FFI calls to Fil-C safe by default (e.g., Fil-C's somewhat looser bounds on what is considered a valid pointer access).