Whether you can a segfault if you access an out-of-bounds address or not is part of the language implementation. An implementation that guarantees a segfault for out-of-bounds accesses is memory safe.

▲

zozbot234 4 days ago | parent | next [-]

You can't really guarantee that all out-of-bounds accesses will segfault, because memory protection mechanisms are not that granular. (And actual memory segmentation, that did have the required granularity, has fallen out of use - though CHERI is an attempt to revive it.) That's why a segfault is treated as something to be avoided altogether, not as a reliable error mechanism.

What you can say though (and the point I made upthread) is that if a language manages to provably never segfault, then it must have some sort of true language-enforced safety because the difference between segfaulting or not is really just a matter of granularity.

▲

uecker 4 days ago | parent [-]

How granular the memory protection mechanism is is part of the implementation.

▲

zozbot234 4 days ago | parent [-]

It's part of the broader system, not the language implementation. And in practice, systems that achieve this are not in common use.

	▲	uecker 4 days ago \| parent [-]
		You are using a narrower definition than me. The language implementation builds on the functionality of the a larger system. An implementation can utilize the functionality of the overall system and close the loopholes. For example, using sanitizer you can turn out-of-bounds accesses to arrays into traps. This is not a segmentation fault but SIGILL, but it also builds on the trapping mechanism to achieve bounds safety (if you limit yourself to arrays).

▲

2 days ago | parent | prev [-]

[deleted]