41
Memory Safety is a Red Herring
(steveklabnik.com)
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
this post was submitted on 24 Dec 2023
41 points (86.0% liked)
Rust
6063 readers
26 users here now
Welcome to the Rust community! This is a place to discuss about the Rust programming language.
Wormhole
Credits
- The icon is a modified version of the official rust logo (changing the colors to a gradient and black background)
founded 1 year ago
MODERATORS
If you had half the experience you claim to have, you'd know that code that triggers UB is broken code by definition, and represents a bug that you introduced.
It's not the language's fault that you added bugs to the code. UB is a red herring.
You missed the whole point of what I said.
By definition, UB does not work. It does not work because by design there is no behavior that should be expected. By design it's up to the implementation to fill in the blanks, but as far as the language spec goes there is no behavior that should be expected.
Thus, code with UB is broken code, and if your PR relies on UB then you messed up.
Nevertheless, some implementations do use UB to add guardrails to typical problems. However, if you crash onto a guardrail, that does not mean you know how to drive. Do you get the point?
Nobody's perfect and time has shown multiple time that you can't trust human beings with memory safety. I.e. the whole 70% of bugs being memory safety bugs thing. Adding bugs to the code isn't the language's fault, but you can't blame a human being (even experts) to do it.
It is however the language's fault to allow UB in the first place. And it's possible to entirely avoid UB in (safe) Rust. So we've seen that the possibility of undefined behavior is not necessary for the vast major of programming. So I would definitely say it's C and C++'s "fault" for allowing UB in the unrestricted way that it does.
Am I blaming those languages? Nah, it was a different time. We didn't have the technology we have now. But going forward there's no reason to use unsafe languages in greenfield projects. We should move forward with safe languages.
That's perfectly fine. That's not a problem caused UB, or involving UB.
Again, UB is a red herring.
It really isn't. Again, mindlessly parroting this doesn't give any substance to this claim. Please try to think about it for a second. For starters, do you believe it would make any difference if the C or C++ standard defined how the language should handle dereferencing a null pointer? I mean, in some platforms NULL is a tombstone, but on specific platforms NULL actually points to a valid memory address. The standards purposely leave this as undefined. Why is that? Seriously, think about it for a second.
It really isn't. It's a design choice that reflects the need to work with the widest possible range of platforms. The standards have already been updated with backwards-incompatible changes, but even the latest revisions purposely include UB.
I repeat: I see people mindlessly parroting nonsense about UB when they clearly have no idea what they're talking about.