3 ms·

> 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. m

> 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.

throwaway894345 5y ago
Data races aren't limited to maps, so I'm not sure it's even a distinction at all :)
- TheDong 5y ago
  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.
  - gpderetta 5y ago
    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.
  - throwaway894345 5y ago
    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).
  - voidnullnil 5y ago
    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-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...
Dylan16807 5y ago
> 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.

throwaway894345 5y ago

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

TheDong 5y ago
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.
- gpderetta 5y ago
  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.
- throwaway894345 5y ago
  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).
- voidnullnil 5y ago
  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-memory-safety.html https://blog.stalkr.net/2015/04/golang-data-races-to-break-m...

Dylan16807 5y ago

> 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.