Hacker News Reader

Comment by TheDong | Hacker News Reader

> Go is type and memory safe if you avoid explicitly unsafe things, except for data races on those structures

Note that this isn't actually a real exception. maps are implemented in the go stdlib using "unsafe", in addition to compiler magic for the generics part.

I believe that it holds that if you don't use "unsafe" then your program is memory and type safe, it just happens that the go stdlib and runtime use "unsafe", so you can't safely use them either.

I get that this is a distinction without a difference.

View on HN

> it just happens that the go stdlib and runtime use "unsafe", so you can't safely use them either.

It's still the job of the code author to make it so you can safely use that code, despite internal use of unsafe.

Data races aren't limited to maps, so I'm not sure it's even a distinction at all :)

I think data-races that can cause undefined behavior are limited to maps and slices and other structures that internally use unsafe.

data-races that can't cause undefined behavior are a different class, closer to what java has, and iiuc that's what you get without unsafe.

I don't think the distinction matters, but I think it exists.

As far as I understand all interface pointers in go are fat pointers to (vtable, object) and as such can't be updated atomically [1]. Hence any data race on assignment to an interface pointer can lead to UB.

[1] unless there is an additional indirection, I don't really know much about go.

They use `unsafe.Pointer`s under the hood, but I'm pretty sure that implementation detail is unrelated to the race condition (the issue with the race condition is that writes of these types aren't atomic so a concurrent thread that is reading the value could observe it in a partially-updated state (e.g., the pointer field has been updated but not the length field).

The slice is simply unsynchronized, so a user of the slice may pull out one array but a length that was for a different array.

https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Reply on news.ycombinator.com