Hacker News Reader

Comment by masklinn | Hacker News Reader

> Can this actually manifest?

Yes. Per rsc (https://research.swtch.com/gorace)

> In the current Go implementations, though, there are two ways to break through these safety mechanisms. The first and more direct way is to use package unsafe, specifically unsafe.Pointer. The second, less direct way is to use a data race in a multithreaded program.

That races undermine memory safety in go has been used in CTFs: https://github.com/netanel01/ctf-writeups/blob/master/google...

These are not idle fancies, there are lots of ways to unwittingly get data races in go: https://www.uber.com/blog/data-race-patterns-in-go.

View on HN

It's interesting that the 2010 article you linked suggests they might consider improving this but nope, Go 1.0 and the Go people use today just basically takes the same attitude as C and C++ albeit with a small nuance.

In C and C++ SC/DRF (Sequentially Consistent if Data Race Free) turns into "All data races are Undefined Behaviour, game over, you lose". In Go SC/DRF turns into "All data races on complex types are Undefined Behaviour, game over, you lose". If you race e.g. a simple integer counter, it's damaged and you ought not to use it because it might be anything now, but Go isn't reduced to Undefined Behaviour immediately for this seemingly trivial mishap (whereas C and C++ are)

Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to, but once you corrupt the map data structure, weird things can happen. Trying to contain that explosion isn't necessarily "better", as it would make maps slower / take up more memory / etc.

> Go doesn't go out of its way to make weird things happen on UB like C compilers these days tend to

The reasons C compilers “tend to go out of their way to make weird things happen” is they optimise extremely aggressively, and optimisations are predicated upon the code being valid (not having UBs).

Go barely optimises at all, and does not have that many UBs which could send the optimiser in a frenzy.

Kind of ironic the raison d'être of Go is a memory safe language for concurrent programming but you can easily footgun yourself into doing something memory unsafe using concurrency...

Go generaly doesn't used shared memory and concurrency, or at least it's been considered an anti-pattern: https://go.dev/blog/codelab-share

That is dishonest.

Implicitly shared memory is literally the default behaviour of the langage, and you have to be careful to keep that controlled or contained.

Pretty much as in every other shared memory concurrency langage.

The quip about sharing memory by communicating is cute but it’s just that, the langage does not encourage let alone enforce it.

In fact it went out of its way to remove some opportunities e.g. because `go` is a statement there is no handle which could communicate the termination and result of routines.

Yes, but at the same time shared memory concurrency is not considered an unsafe usage of Go either...

This is a CTF challenge where attackers control the code that's running, isn't it?

Reply on news.ycombinator.com