4 ms·
“Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.
by sagichmal 7y ago
“Memory safe” has a specific technical definition, and “atomic assignment” isn’t it.
- burntsushi 7y agoNo, the GP is correct. Data races are undefined behavior, and break memory safety: https://research.swtch.com/gorace https://research.swtch.com/gorace
- pwodhouse 7y agoIs there a sense in which Russ's claim that "data races are not security problems" is true? It seems to be assuming that data races are impossible to exploit by users (data input), only by programmers.
- kibwen 7y agoPresumably because data races are so inconsistently triggered that creating a reliable exploit would be generally infeasible, even with control over user input. However, this unpredictability is also why data races (among other concurrency issues) are some of the most maddening types of bugs to observe, hunt down, and diagnose, which is why eliminating data races is actually a big deal for anyone who's ever wrestled with threads before.
- 0815test 7y agoGo is indeed memory-safe for sequential code, but non-atomic assignment can definitely break memory safety in multi-threaded settings - it's effectively a data race.