Crashing on shared access is the safe thing to do

An intentional exit by a runtime is a safe crash. A segfault is not, and is here a clear sign that memory safety has been violated.

	▲	Gibbon1 5 days ago \| parent \| next [-]
		Yeah it's not the segfault that's bad, it's when it's when the write to address 0x20001854 succeeds and now some hapless postal clerk is going to jail.
	▲	adamwk 5 days ago \| parent \| prev [-]
		I guess I was thinking specifically of the swift case where values have exclusive access enforcement. Normally caught by a compiler, they will safely crash if the compiler didn’t catch it. I think the only way to segfault would be by using Unsafe*Pointer types, which are explicitly marked unsafe

sapiogram 5 days ago | parent | prev | next [-]

"Crashing" is a very positive spin. "The heap getting the corrupted until it was killed by the operating system" is another interpretation.

LtWorf 5 days ago | parent | prev [-]

a segfault is completely unintentional. Had the kernel been older it could be used to execute code.

> a segfault is completely unintentional

> Faulted trying to access 0x10 - the offset in the string we were trying to read from :)

Is guaranteed that every offset you can try to read is guaranteed to create a segfault?

	▲	cesarb 4 days ago \| parent [-]
		> Is guaranteed that every offset you can try to read is guaranteed to create a segfault? The offset is fixed as part of the compiled code; the JVM can enforce that it's less than 4k (otherwise it can use an explicit NULL check), and that the first 4k page is always unmapped.