Yeah, to be clear, some domains are different. Gaming is one example of a domain where "best effort" memory safety is perfectly acceptable. Would I prefer full memory safety? Sure, but we don't see games as an attack vector in the wild very often and there are good reasons for that.
If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much.
But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.
Even without it being an attack vector, memory unsafety in games can suck as a user. I play a game that’s high stakes, when you die you lose your gear. I’ve lost two full sets of endgame gear recently because of a crash due to an EXCEPTION_ACESS_VIOLATION. I found it kinda funny in a dark way. Anyway, cheats can also happen due to these sorts of issues. And let’s not even start about anticheat; if Battleye or god forbid Vanguard has a memory unsafety issue that’s exploitable, a lot of people are going to be in a very bad place.
Single player games maybe but they can still cause problems the end user sees.
EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error. It's correctness that affects the user experience, not memory safety.
From a cheating perspective, memory safety is entirely irrelevant when the game code is running on the users' computers, where they have full control over the machine code of the client, their own RAM, and the bytes being sent to the network.
There are plenty of important use cases to care about memory safety, but video games executing on players' computers ain't it.
> where they have full control over the machine code of the client,
Part of the state of modern anti-cheat is developers taking extreme measures to fight exactly this. Developers don’t just throw their hands up in the air and say it’s unfixable. The softwares I mention run as kernel modules, hook into all sorts of parts of your system, and sometimes even stream new mitigations to be executed as the game is running. That’s why an RCE in this software would be extremely bad.
EXCEPTION_ACCESS_VIOLATION itself is well-defined and memory safe, but the program constructs that cause it are generally not. A use-after-free or null pointer dereference may cause an access violation in one run but corrupt memory and keep going in another. This is a very typical approach to building an exploit- find something like this and then tweak the input to turn it into something worse.
This also plays into undefined behavior- unless the source language itself guarantees that a particular program will generate an access violation, chances are the access violation only happens by luck. For example, null pointer dereference is typically UB rather than specified as a crash, because while accessing the actual address 0 will reliably cause an access violation (assuming you are in such an environment), field projection and array indexing can move that address up out of the 0 page and lead to arbitrary memory access.
> EXCEPTION_ACCESS_VIOLATION is well-defined & memory safe. That's just a crash, same thing that happens when Helix crashes because it called .unwrap() on an error.
Just because both of those things cause a crash doesn't mean they are the same.
Crashing due to an incorrect .unwrap() is a bug in the business logic of the application, the developer made a wrong assumption.
EXCEPTION_ACCESS_VIOLATION is a crash due to a memory issue that a memory safe language would have prevented.
> It's correctness that affects the user experience, not memory safety.
Memory safety is part of correctness, your program can't be correct if it crashes with EXCEPTION_ACCESS_VIOLATION.
Sure, I think all developers, virtually regardless of domain, should strive for higher quality software. The bar is really low. But the fight I choose is memory safety in cases where end user security will be harmed without it - to me, that's such a pathetically low bar already, surely people can't argue against it (they can and they do lol I hate this industry tbh).
I'm not sure I'd characterize Rust as an easy enough option for most people/cases, or that there's just a "few" situations, but apart from that I like your perspective, well said.
If someone wants to build a game in a language that's best-effort memory safety go for it. Similarly, CLI applications are often never called from an untrusted context and often provide semantic power that is equivalent to code execution anyways, so again I'd love to see memory safety, but I'm not going to care that much.
But these are exceptions - you'd still want to way whatever you're getting from memory-unsafe-language-X against just using a memory safe language. The default should be memory safety. Given that we have Go, Rust, Java, and more, there are few situations where memory safety isn't an easy option. Not zero, just few.