5 ms·
> the problem might not be so localized as the notion of "only auditing unsafe blocks is sufficient" implies It depends on what you consider "problem" can mean
by dwattttt 2y ago
> the problem might not be so localized as the notion of "only auditing unsafe blocks is sufficient" implies
It depends on what you consider "problem" can mean. An unsafe function needs someone to write unsafe in order to call it, and it's on that calling code to make sure the conditions needed to call the unsafe function are met.
If that function itself is safe, but still let's you trigger the unsafe function unsafely? That function, which had to write 'unsafe', has a bug: either it's not upholding the preconditions of the unsafe function it's calling, or it _can't_ uphold the preconditions without their own callers also being in on it, in which case they themselves need to be an unsafe function (and consider whether their design is a good one).
In this way, you'll always find unsafe 'near' the bug.
- uecker 2y agoIn other words, somebody made an error somewhere.
- dwattttt 2y agoYou're thinking of C; Rust forced that somebody to write unsafe near it to create the bug.
- uecker 2y agoThe bug that can lead to a violation of assumptions required for safety of the unsafe block can be elsewhere. One can hope that it is near the bloc, but there is nothing in Rust enforcing this.
- Dylan16807 2y agoWhen you write "unsafe", you are promising to the compiler that the unsafe code enforces the assumptions it is making. Unsafe code needs to keep its assumption-laden variables private, and it needs to verify the parameters that safe code sends it. If it doesn't do those things, it's breaking that promise.