4 ms·
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 ff
by QuaternionsBhop 2mo ago
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.
- inigyou 2mo agoHow does it prevent multiple mutable pointers?
- aw1621107 2mo agoMultiple mutable pointers are fine. You need to be careful to ensure you don't turn them into multiple coexisting mutable references, though.
- inigyou 2mo agoNice pedantry. How does it prevent multiple coexisting mutable references?
- aw1621107 2mo agoI'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).
- BobbyTables2 2mo agoIt’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…