5 ms·

What's the typical definition? With data races, you can access array values out-of-bounds, which seems like the most fundamental thing you'd want protection fr

by panic 9y ago

What's the typical definition? With data races, you can access array values out-of-bounds, which seems like the most fundamental thing you'd want protection from in a memory safe language.

pjmlp 9y ago
The typical definition is memory corruption caused by out of bounds writes, stack corruption, use after free. On safe languages an out-of-bounds will cause a crash on the access point, while on unsafe languages it will silently corrupt memory.
zaarn 9y ago
You can't access data out of bounds. Go will panic with a runtime exceptions if you do. Memory safety doesn't mean "memory IO errors never happen" it means "if a memory IO error happens, you'll know" If you have an out of bound in C, your program keeps running in 9/10 cases. In Go you'll cause a panic in 10/10 cases which you can either handle and propagate as error or let the program crash entirely, the memory will be in a defined state if you choose to recover (your array might be garbage but you won't have written data into random memory belonging to other threads)
- millstone 9y ago
  But with Go you CAN access data out of bounds. See the "Exploiting the slice type" section where writing to a slice modifies a function pointer which happens to be stored after the slice. It's an OoB write which does not panic.
  - zaarn 9y ago
    an OoB write under a data race in a program that won't occur like this in the wild. The conclusion section of the post you mean contains that statement too. The %p formatting used to gain access to the pointer of a variable uses the unsafe package, the formatting itself is incredibly rarely use to begin with. I don't see anybody doing any security-related exploits doing that unless you explicitly write for it. Go won't do out of bounds, edges cases do happen. You can find the same stuff on Java and Rust (yes, I had OoB in Rust, though on a baremetal environment without OS, even Rust ain't safe.)

by panic 9y ago

What's the typical definition? With data races, you can access array values out-of-bounds, which seems like the most fundamental thing you'd want protection from in a memory safe language.

pjmlp 9y ago

The typical definition is memory corruption caused by out of bounds writes, stack corruption, use after free. On safe languages an out-of-bounds will cause a crash on the access point, while on unsafe languages it will silently corrupt memory.

zaarn 9y ago

You can't access data out of bounds. Go will panic with a runtime exceptions if you do. Memory safety doesn't mean "memory IO errors never happen" it means "if a memory IO error happens, you'll know" If you have an out of bound in C, your program keeps running in 9/10 cases. In Go you'll cause a panic in 10/10 cases which you can either handle and propagate as error or let the program crash entirely, the memory will be in a defined state if you choose to recover (your array might be garbage but you won't have written data into random memory belonging to other threads)

millstone 9y ago
But with Go you CAN access data out of bounds. See the "Exploiting the slice type" section where writing to a slice modifies a function pointer which happens to be stored after the slice. It's an OoB write which does not panic.
- zaarn 9y ago
  an OoB write under a data race in a program that won't occur like this in the wild. The conclusion section of the post you mean contains that statement too. The %p formatting used to gain access to the pointer of a variable uses the unsafe package, the formatting itself is incredibly rarely use to begin with. I don't see anybody doing any security-related exploits doing that unless you explicitly write for it. Go won't do out of bounds, edges cases do happen. You can find the same stuff on Java and Rust (yes, I had OoB in Rust, though on a baremetal environment without OS, even Rust ain't safe.)