4 ms·
> because data races in the presence of memory safety are not a big deal from a security standpoint. Note though that data races can make otherwise memory-safe
by SkiFire13 1y ago
> because data races in the presence of memory safety are not a big deal from a security standpoint.
Note though that data races can make otherwise memory-safe programs not actually memory safe. See for example Go
- pizlonator 1y agoWhat’s the problem with Go?
- aw1621107 1y agoIIRC slices aren't updated atomically in Go so you can get data races on their components, resulting in potential UB. For what it's worth, from what I've read on here (e.g., [0]) this has yet to be exploited in a non-demonstration setting, but who knows if/when the first such exploit will appear. [0]: https://news.ycombinator.com/item?id=42043939 https://news.ycombinator.com/item?id=42043939
- pizlonator 1y agoI think that just means that Go isn't completely memory safe. Or, it means that "Go is only memory safe provided you have no data races". My point is that it's weird to say that there is a notion of memory safety that is separate from the memory safety you get if you also have a story for data races. It leads to exactly the confusion in the OP: it's not clear if they're saying that memory safety subsumes data race freedom in the sense that you're memory-safe even in the presence of races (like Java or Fil-C), or that it means that memory safety subsumes data race freedom in the sense that Rust's type system handles both memory safety and data races using the same basic technique.
- aw1621107 1y agoRight, I get what you're saying and think you have a point. Just wanted to expand on the (perceived?) issue with Go and data races.