I don’t think that casting a range of bits as some other arbitrary type “is a bug nobody sees coming”.
C++ compilers also warn you that this is likely an issue and will fail to compile if configured to do so. But it will let you do it if you really want to.
That’s why I love C++
That’s not what I meant. I understand that rust forces things to be more secure. It’s not not like there’s some guarantee that rust is automatically safe, and C++ is automatically unsafe.
I want you to imagine that your comments in this thread were written by an engineer or a surgeon instead of a programmer.
Imagine an engineer saying “Sure, you can calculate the strength of a bridge design based on known material properties and prove that it can hold the design weight, it that doesn’t automatically mean that the design will be safer than one where you don’t do that”. Or “why should I have to prove that my design is safe when the materials could be defective and cause a collapse anyway?”
Or a surgeon saying “just because you can use a checklist to prove that all your tools are accounted for and you didn’t leave anything inside the patient’s body doesn’t mean that you’re going to automatically leave something in there if you don’t have a checklist”. Or “washing your hands isn’t a guarantee that the patient isn’t going to get an infection, they could get infected some other way too”.
A doctor or engineer acting like this would get them fired, sued, and maybe even criminally prosecuted, in that order. This is not the mentality of a professional, and it is something that programming as a profession needs to grow out of.
Every single doctor should know this yes.
It seems people are adding a sentence I didn’t say “rust can be unsafe and thus we shouldn’t try” on top of the one I did say “programmers should be aware that rust doesn’t automatically mean safe”.
Then you should probably be a little more explicit about that, because I have never, not once in my life, heard someone say “well you know wearing a seatbelt doesn’t guarantee you’ll survive a car crash” and not follow it up with “that’s why seatbelts are stupid and I’m not going to wear one”.
We need to stop attaching shit someone doesn’t say to something they did. It makes commutating hostile and makes you an asshole.
Edit: okay that was a bit rude. But it’s so frustrating to say something and then have other people go “that means <this other thing you didn’t say>!!!11!”
I understand your frustration and I apologize for reading into your comments something you didn’t mean. I, too, wish people would say what they mean and mean what they say, and that when you say something its taken to mean what you said.
Unfortunately very often people will make a very reasonable (even factually true) point as a preamble to support something very unreasonable. If you agree with the reasonable point the person will then act like you agree with the unreasonable one. This is not only more time consuming and tiring to argue against, it also lends a great deal more credibility to the unreasonable point than it is really owed. To the uninformed reader to looks like the two sides of the argument partially agree, when nothing could be further from the truth. Its immensely frustrating to have your words used against you like this, so many people try and preempt it by jumping straight to (what they assume to be) the unreasonable point and arguing against it directly.
This is toxic for actual discussion. It means that good faith actors have to add all sorts of qualifications and clarifications about where they stand before they say anything about anything, which is tiring in itself. But its the world that we live in. If someone makes an unqualified comment about the CO2 emissions of volcanoes in a thread about anthropogenic climate change people are going to assume that they don’t think climate change is real. And, operating that way, those people will be right more often than they’re wrong.
Safe in what regards? You’re being cagey on purpose. In terms of memory there is a guarantee that Rust is automatically safer than c++, period. Im business Logic? Sure you’re right
No there is not. Borrow checking and RAII existed in C++ too and there is no formal axiomatic proof of their safety in a general sense. Only to a very clearly defined degree.
In fact, someone found memory bugs in Rust, again, because it is NOT soundly memory safe.
Dart is soundly Null-safe. Meaning it can never mathematically compile null unsafe code unless you explicitly say you’re OK with it. Kotlin is simply Null safe, meaning it can run into bullshit null conditions.
The same thing with Rust: don’t let it lull you into a sense of security that doesn’t exist.
Wat? That’s absolutely not true; even today lifetime-tracking in C++ tools is still basically a research topic.
It’s not clear what you’re talking about here. In general, there are two ways that a language promising soundness can be unsound: a bug in the compiler, or a problem in the language definition itself permitting unsound code. (
unsafechanges the prerequisites for unsoundness, placing more burden on the user to ensure that certain invariants are upheld; if the code upholds these invariants, but there’s still unsoundness, then that falls into the “bug in Rust” category, but unsoundness of incorrectunsafecode is not a bug in Rust.)Rust has had both types of bugs. Compiler bugs can be (and are) fixed without breaking (correct) user code. Bugs in the language definition are, fortunately, fixable at edition boundaries (or in rare cases by making a small breaking change, as when the behavior of
extern "C"changed).Have you heard about cve-rs?
https://github.com/Speykious/cve-rs
Blazingly fast memory failures with no unsafe blocks in pure Rust.
Edit: also I wish whoever designed the syntax for rust to burn in hell for eternity
Edit 2: Before the Cult of Rust™ sends their assassins to take out my family, I am not hating on Rust (except the syntax) and I’m not a C absolutist, I am just telling you to be aware of the limitations of your tools
So now we’re considering bugs in the compiler as bugs in the language?
A) Rust doesn’t have a formal specification other than “whatever the fuck our team hallucinated in this compiler version”
B) Doesn’t matter the definition if it fucks your day because you’re not careful.
Sure sure Heil Rust but be mindful of the fuck you’re doing before you get bit ¯\_ (ツ) _/¯
That’s simply not true. The Reference, while not an ISO-style formal spec, does actually specify most of the intended language behavior, and incrementally approaches completion over time. But even if you insist on an ISO-style formal spec, there’s Ferrocene: https://ferrous-systems.com/blog/the-ferrocene-language-specification-is-here/
The
cve-rsvulnerability is actually not really something you’d ever write by accident. Also note that the bug report has multiple versions because, even though a “full” solution is pending some deeper compiler changes, the first two versions of the exploit are now caught by the compiler. So, like I said, the compiler bugs do get fixed over time.Yeah, and that falls under the first category, bugs in the compiler: https://github.com/rust-lang/rust/issues/25860
(All exploits in that repo are possible due to that bug.)
Yeah and those are the ones currently identified (btw that issue isn’t completely fixed) because rust never was nor advertised itself as sound. Meaning, you gotta be careful when writing Rust code too. Not as much as C++, but it’s not a magical shield against memory problems like people have been shilling it as.