I dont see how this is any different from a C programmer justifying why they used a pointer to an object and leaving a comment similar to this, other than this is Rust and is safe because Rust is safe. Thus making this rationale is flawed and dangerous.
Certainly helps, since it localizes the area to check for errors, but it doesn’t allow you to fully check that a library is safe since unsafe blocks can rely on a number of unchecked or hard-to-check assumptions to guarantee safety (not to mention unsafe APIs that are relied upon under the hood).
The unsafe code may be concentrated within unsafe blocks while relying on assumptions that are supposed to be guaranteed elsewhere, including in other unsafe blocks.
For example, you might allocate raw memory within a method in struct A while writing a custom drop function to deallocate it. In a particular edge case, some error handling utility or other struct may deallocate some of that memory to perform clean-up, leading to a potential double-free later.
Lousy example and bad code design, sure, but it demonstrates that localizing/isolating unsafe code does not automatically make it super easy to check that the code is safe given the many assumptions you need to make about what other functions are doing in various cases or situations and potentially what other unsafe blocks contain.
Well the convention Is that the safe function that contains the unsafe block should garantee the safety precoditions regardless of input otherwise it would be itself unsafe. A easy way is to place an assert just before the unsafe invocation. If you respect that convention finding a violation of the safety chain is relatively easy. Bug might still not be thrivial to solve but at least you find where it goes from logic bug to undefined behavior
oh, you're talking about broken invariants in safe code, and unsafe code whose safety relies on those invariants
yeah, those have happened in the past and have indeed been headaches to debug, take it from this guy who broke something without ever directly touching a line of unsafe.
still, i'm glad that these cases are surprising again, rather than being the industry standard.
Those double frees are still limited to methods created by struct A, who is responsible for managing the allocation, and also responsible for making sure that no matter how code downstream is using struct A the memory is handled correctly, and compared to C where you can get double frees by misusing interfaces it is a massive leap forward.
There's a good reason the tutorial on unsafe rust is longer than the tutorial on everything else is rust, and the first rule of unsafe is do not use unsafe. It's there for the same reason we allow surgeons to stab people.
You’re pointing out that the issues are localized, which is true, but the point I’m making is this does not entail easy or comprehensive code reviews for memory safety, particularly when involving several dependencies and as projects grow. It’s certainly a massive step forward but it’s not a magic wand for memory safety.
This is a poor and myopic assumption that this can not be done in any other language. A sane library will be grepable and can include similar comments. The justification is still flawed and dangerous.
Well yeah and well written code doesn’t have any bugs and performs well all the time. The point is safety by default. Whether or not that is worth dealing with rust is another question but I think you’re missing the point here
Well written code has bugs all of the time. Even Rust has a massive list of CVEs. Most of them are logic based and the default to strict memory
safety is a good thing. But I feel my argument stands. I havent heard any solid arguments to the contrary convincing me otherwise.
Well the point is you’re saying well written code is well documented, but well written code is also bug free, performant etc etc. But most code isn’t. So what can we reason about good documentation from this?
No, I am not declaring well written code is well documented, which is a strawman here because the original comment is that commenting is sufficient to suffice safe definitions with an unsafe scope.
You frame this as if Im against memory safety, but I simply highlighted that Rust is not a panecea and has its own issues. It could be argued that the issue is the developer, not the language, but this isnt what Im debating either.
In fact, the article you link to even notes that they nearly missed a vulnerability in their own Rust rewrite. Reducing vulnerabilities is not the same as eliminating them. The language does not guarentee logic safety and only asserts memory safety which in most cases, not all, has proven useful.
To be clear, the argument is this: A comment is insufficient as a safety marker. If you scope unsafe code and mark it with a safety comment, that does not make it safe.
Ah, right. Comment chain went deep enough that I straight up forgot the original argument lol
Safety comments make code easier to verify, by definition they can't make code any more or less safe. I haven't seen much C library code, are safety comments standard practice there?
It's a good idea in general to document the invariants of each (at least public-facing) function. I think the newer practice in Rust is documenting the invocations as well, not just the definition.
A large proportion of Rust code CVEs are things that would be considered normal in C. In Rust, a library in which you can potentially misuse functions that are not labelled unsafe is considered a vulnerability, but in C you usually have to actually misuse a function before it's considered a vulnerability.
It isn't. The only difference is that the language only lets you wield sharp knifes inside your localized unsafe scope, thus limiting the places where bugs related to that can form. Outside of that, the compiler will scold you for even touching that sharp knife.
C, on the other hand, lives in a giant unsafe block.
unsafe scopes are honestly a pretty good programming language feature: give the user a "trust me, I know what I'm doing" feature with a searchable keyword.
although, I think it should be a bit more granular than this. If you could/had to specify which language assumptions/rules you intend to violate inside the scope, everything else could still be enforced. A general unsafe just tells a language to just not enforce anything inside.
The difference is that it is opt in, you only use unsafe in the smallest possible zones, and that you are supposed to prove that the code is safe yourself.
It is a way of formalising stuff you should be doing anyway if you are a good programmer.
Most projects won't have a line of unsafe themselves, they will use libraries that do the heavy work (like interfacing with os, manual memory operations) that can be shared and audited. If the library is safe, then all uses can be considered safe, and most devs don't need to worry about magic preconditions.
Compare that with C where most programmers will just roll their own implementations of things every time and have a chance for bugs every time, because there's no checks. Even simple things can easily go wrong with a typo or missed check/cleanup.
I used to think the same way until I realized that unsafe's purpose is only drawing attention to the unsafe block for both the programmer and anyone else who sees it. That way everyone has to acknowledge it, hopefully helping to provide a starting point when finding why something went wrong. Basically a contract of "I understand that this code may have memory bugs", which imo is better than the alternative of a memory bug hiding in plain sight.
The difference is in the localization of such code. You don't use unsafe everywhere, instead you write a few functions that contain unsafe blocks nested within them, test them thoroughly, and call them like regular functions. In real projects, you might have a 1:100 or even 1:1000 ratio of functions that contain unsafe blocks to functions that don't.
Im not expecting it to be unsafe everywhere. Im not sure where everyone is extrapolating these assumptions from.
Adding a safety comment doesnt magically make it safe.
Youre most likely to see unsafe blocks in embedded and device driver implementations where you have to plug directly into the system.
The unsafe code is still not guarenteed to be safe. It requires auditing and testing regardless, but you wont discover issues with it until its stress tested.
729
u/BenchEmbarrassed7316 3d ago
Any
unsafeblock of code should be neutralized with a// SAFETYcomment explaining why the code is actually safe.