Yeah what I said is true of TS and C#, but not of Go.
Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.
Yeah what I said is true of TS and C#, but not of Go.
Go’s situation is nuanced since a lot of Go code does rely on unsafe C or C++ deps, but I have no idea how generally true that is. Also Go’s protections fall apart under certain races, which isn’t true in Fil-C.
Races in Fil-C allow access to one object through a pointer to a different object if there's an attacker-controlled offset involved.
Fil-C's safety guarantees therefore fail to apply in this situation.
Nonsense.
In a race, you at worst access an object you could have loaded from whatever field you were racing on.
In Go, you can bypass all protections and corrupt all of memory if you race on structs (I think).
3 replies →