Another canard, unfortunately. "Segfault" is simply Go's reporting convention for things like nil pointer hits. "Segfaults" are not, in fact, part of the definition for memory safety or a threshold condition for it. All due respect to Ralf's Ramblings, but I'm going to rest my case with the Prossimo page on memorysafety.org that I just posted. This isn't a real debate.

▲

vlovich123 9 hours ago | parent [-]

> Segfault" is simply Go's reporting convention for things like nil pointer hits.

Blatantly false. From Ralf’s post:

> panic: runtime error: invalid memory address or nil pointer dereference [signal SIGSEGV: segmentation violation code=0x1 addr=0x2a pc=0x468863]

The panic address is 42, a value being mutated, not a nil pointer. You could easily imagine this address pointing to a legal but unintended memory address resulting in a read or write of unintended memory.

▲

tptacek 9 hours ago | parent [-]

No, you can't, and the reason you know you can't is that it's never happened. That looks like a struct offset dereference from a nil pointer, for what it's worth.

https://go.dev/play/p/0fUzmP0cLEa

▲

vlovich123 7 hours ago | parent [-]

You’d be wrong. I recommend you reread the blog post and grok what’s happening in the example.

> When that happens, we will run the Ptr version of get, which will dereference the Int’s val field as a pointer – and hence the program accesses address 42, and crashes.

If you don’t see an exploit gadget there based on a violation of memory safety I don’t know how to have a productive conversation.

	▲	tptacek 5 minutes ago \| parent [-]
		Please do explain the exploit gadget you're talking about.