2 ms·
IIRC 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
by aw1621107 1y ago
IIRC 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.