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++
I actually do like that C/C++ let you do this stuff.
Sometimes it’s nice to acknowledge that I’m writing software for a computer and it’s all just bytes. Sometimes I don’t really want to wrestle with the ivory tower of abstract type theory mixed with vague compiler errors, I just want to allocate a block of memory and apply a minimal set rules on top.
100%. In my opinion, the whole “build your program around your model of the world” mantra has caused more harm than good. Lots of “best practices” seem to be accepted without any qualitative measurement to prove it’s actually better. I want to think it’s just the growing pains of a young field.
People just think that applying arbitrary rules somehow makes software magically more secure, like with rust, as if the compiler won’t just “let you” do the exact same fucking thing if you type the
unsafekeywordYou don’t need
unsafeto write vulnerable code in rust.https://github.com/Speykious/cve-rs
Yes I know there are other ways to do it. That’s one way.
I want you to stop what you’re doing, pause and read your comment again slowly. What you’re arguing is analogous to: “People just think that strapping a cloth to them in the car will make driving more secure. As if someone can’t just not use the seatbelt and still die in a car crash from that.”
It’s not arbitarious rules, it’s math and computer science. Wth are you some kind of science denier? Have they reached the computer science realm, like “Big O is out to get you?”
These rules do make Rust safer than c++ not in term of business logic but in terms of memory handling. I’ve been doing c++ for a looooooong time and once in a while there are times where we lose days if not weeks tracking down a race condition or memory bug where we could have been tracking down business logic bugs, improving code quality and coverage, adding features, etc
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.
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
It’s neither arbitrary nor magic; it’s math. And
unsafedoesn’t disable the type system, it just lets you dereference raw pointers.You don’t even need
unsafe, you can just take user input and execute it in a shell and rust will let you do it. Totally insecure!Rust isn’t memory safe because you can invoke another program that isn’t memory safe?
My comment is sarcastic, obviously. The argument Kairos gave is similar to this. You can still introduce vulnerabilities. The issue is normally that you introduce them accidentally. Rust gives you safety, but does not put your code into a sandbox. It looked to me like they weren’t aware of this difference.
I don’t know rust, but for example in Swift the type system can make things way more difficult.
Before they added macros if you wanted to write ORM code on a SQL database it was brutal, and if you need to go into raw buffers it’s generally easier to just write C/objc code and a bridging header. The type system can make it harder to reason about performance too because you lose some visibility in what actually gets compiled.
The Swift type system has improved, but I’ve spent a lot of time fighting with it. I just try to avoid generics and type erasure now.
I’ve had similar experiences with Java and Scala.
That’s what I mean about it being nice to drop out of setting up some type hierarchy and interfaces and just working with a raw buffers or function pointers.