5 ms·
Calling an unsafe function can only be done inside an unsafe block.
by burntsushi 6y ago
Calling an unsafe function can only be done inside an unsafe block.
- saagarjha 6y agoI’m unsure what you’re responding to. As I understood it, the comment took issue with saying that you can make guarantees about safe Rust but not unsafe Rust because unsafe Rust is not verified in that way and opens the door to violating guarantees in your “safe” code if your bugs leak out.
- PudgePacket 6y agoCan you rephrase or restate your point? It's really hard to understand..
- burntsushi 6y agoThat may be what you understood, but that's not what Animats said. See my reply above for more of an elaboration: https://news.ycombinator.com/item?id=24028359 https://news.ycombinator.com/item?id=24028359
- the_duke 6y agoI assume OP s point is that unsoundness or UB in an unsafe block is not contained in that block, but can taint safe code anywhere in the program. Which is true.
- XMPPwocky 6y agoonly 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.)
- tsimionescu 6y agoBut you can expose unsafe code with a safe API, right? The point of the GP was that any safe code using this safe API could in fact be memory unsafe is there is a bug in the unsafe implementation.
- imtringued 6y agoYes but it's easy to take this too far and conclude that e.g. Javascript is not memory safe because browsers are written in C++ and they have to interface with the kernel which is written in C. At some point you simply need to trust that the current implementation is correct and bug free. This is also a problem with formal verification. What verifies the verification?
- burntsushi 6y agoYes, of course you can. But that's not what Animats said. Animats specifically said "unsafe function," which means you need to use the unsafe annotation to call it. See my other reply for more elaboration: https://news.ycombinator.com/item?id=24028359 https://news.ycombinator.com/item?id=24028359
- jfkebwjsbx 6y agoThey say can call though, so they are correct: if you can call then you are in an unsafe context.
- burntsushi 6y agoYes...? But they're responding to a point about safe Rust. See my other comment: https://news.ycombinator.com/item?id=24028359 https://news.ycombinator.com/item?id=24028359
- Animats 6y agoThe function containing the unsafe block can be called from safe code. So unsafe functionality can be exported. Said unsafe functionality might not be safe for all possible inputs. That's a classic hole, as with APIs that can be exploited.
- burntsushi 6y agoThen that's a "function containing an unsafe block," not an "unsafe function." In any case, this is still a misunderstanding of what staticassertion said. I elaborated more here: https://news.ycombinator.com/item?id=24028359 https://news.ycombinator.com/item?id=24028359 My bigger point here is that you're misunderstanding the advocated Rust value proposition. The value proposition isn't literally "Rust will forever and always eliminate all memory safety bugs in safe Rust." That's silly and no serious person with any credibility would double down on that claim.