Comment by ronsor 9 days ago
You shouldn't be modifying any variable concurrently without a mutex. The only exception to this is if the variable is (1) less than or equal to the CPU word size; (2) is at a CPU word size aligned address; and (3) atomic memory access functions are used to read and write the variable.
Isn't this part of the Go memory model (https://go.dev/ref/mem)?
Memory safety as long as you don't violate certain rules is what C and C++ also have. The problem is that programmers make mistakes because we're all human.
No, the "mistakes" we talk about with C/C++ are so common that it's hard to think of a major C/C++ project not to have them, and the "mistakes" we're talking about with Go or "unsafe" Rust are contrivances built to demonstrate things an actively malicious programmer could do. Equating the two is, obviously, a sleight of hand.
To add to this: the built in go race detector is very good at catching data races. It’s a runtime, but I’ve never had a race that couldn’t be reproduced in the race detector trivially.
But yes, in theory Go has a memory safety problem because of it. In practice though, it’s that people don’t use the race detector, which is ridiculously easy to do.
That's not true: idiomatic Rust projects use `unsafe` much more liberally than other languages use FFI, because of shared xor mutable. That's not a knock on Rust. I couldn't be less interested in Rust vs. Go; I use both and would use them both in different situations.
> Memory safety as long as you don't violate certain rules is what C and C++ also have
There are numbers between 0% and 100%, thus it's possible that Go can be less than 100% memory safe and still far safer than C or C++.
"100% memory safe" is mostly not a thing; it's not a concept that gets quantified this way. The closest thing I think you get to a compromised notion of safety that's actually noteworthy is Zig's allocator behavior (which can in ordinary code theoretically still produce UAF bugs, and UAF bugs --- lifecycle bugs more generally --- are the most pernicious kind of memory safety vulnerability). Most practitioners would still call Zig "memory safe". You can see how much bigger a deal that behavior is than the one we're talking about.
I think the basic takeaway here is not to tie yourself up in nots trying to quantify memory safety. There's a reason Prossimo calls Go memory safe (not "mostly memory safe"), along with Rust, C#, Java, Swift, Python, and JavaScript. Ordinary code written in any of these languages is just not going to have exploitable memory corruption vulnerabilities. Other vulnerabilities, yes!
Even when a value satisfies these architecture-dependent requirements, the language still does not guarantee atomicity of concurrent reads/writes, and programs which rely on that assumption are buggy.