4 ms·
only if that block, or something in its "trusted set" (my term, for things in the same module that can access private members) is incorrect, though. safety/uns
by XMPPwocky 6y ago
only if that block, or something in its "trusted set" (my term, for things in the same module that can access private members) is incorrect, though.
safety/unsafety in Rust is factorable, which is a key part of the reason Rust is useful at all.
- vinay_ys 6y agoRest of your program blindly believes that the interface of your "trusted set" is safe because you owned that responsibility when you marked it unsafe. If you have a memory safety bug in that interface, then you can taint the rest of the program's memory safety as well, correct?
- PudgePacket 6y agoYes, that's the whole point though.
- ridiculous_fish 6y agoI think that is too strong. Consider this code: unsafe { libc::fork() }; let v = vec![1]; This may hang or even crash (malloc in the child) but there's no sense in which the unsafe block is "incorrect." Some unsafe code has unavoidable implications for the entire program.
- burntsushi 6y agoIndeed, some uses of unsafe aren't meaningfully factorable. File backed memory maps or shared memory with other processes are other important real world examples that are difficult or impossible to meaningfully factor in the context of a single process. But I still think that saying "safety in Rust is factorable" is accurate beyond a mere first approximation. Figuring out how to encapsulate unsafety is, in my experience, the essential creative aspect to using unsafe at all. Because if safety wasn't something you could encapsulate, then Rust really wouldn't be what it is. (I have spent many long hours thinking about how and to what extent the safety of file backed memory maps could be encapsulated. Which is to say, factoring safety is really the ultimate goal, even if certain things remain beyond that goal.)