One can evaluate Go using the extent of the definition from the site itself, which uses out of bounds reads and writes as a sign of memory unsafety.
Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)
And then note that memorysafety.org says this (in case folks haven't read it):
> Memory safety is a property of some programming languages that prevents programmers from introducing certain types of bugs related to how memory is used.
They then provide an examine of out-of-bounds read/write. Which is the exact example I noted in my linked comment.
(Note: memorysafety.org does not provide a concrete definition of memory safety, but we get enough from what it says in this case)
The site does not require the known existence of an exploit in popular software (and does not require that _any_ exploit be possible, a bug is sufficient), merely that the language fails to block "certain types of bugs".
Here's an example where a bug could exist in go due torn writes in a real program.
I found this by searching for places where folks reload there config at runtime, as they are generally a place where people forget to synchronize correctly in go.
3. Note that in Go, slices are objects composed of 3 words (https://go.dev/blog/slices-intro#slice-internals) And there isn't syncronization built-in over updating them. As a result, if something reads the slice while it's being updated we will mix together a data pointer & length & capacity that correspond to different real slice objects. If the length we read is from a slice that has real length 10, but the data pointer we read is from a slice with real length 1, when iterating we'll read memory out of bounds.
4. in the context of this particular program, we may send SMSs to recipients who were never in the configured list if a config change occurs at the right time. Or a segfault. Entirely unclear if reading the memory will result in reasonable behavior.
Note: I'm not familiar with this repo otherwise. This is from a quick search.
Go's implementation allows torn writes for interfaces (which are 2 words in size). These torn writes allow arbitrary memory reads/writes (a superset of out of bounds reads/writes)