<div class="gmail_quote">On Sun, Oct 16, 2011 at 11:54 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor.f.gyolchanyan@gmail.com">gor.f.gyolchanyan@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

If the user tries to read unallocated memory, the memory can't<br>
possibly get corrupted, since nothing is getting changed.<br>
If the user tried to write to unallocated memory, the segfault should<br>
_prevent_ it by throwing an OS-level exception (the sigsegv). Throwing<br>
if _after_ the invalid write makes no sense. You can't save anything,<br>
because your own data is not touched. Depending on the implementation,<br>
either some other process's memory would be touched or nothing at all<br>
(internally unmapped region).<br>
I think the rumors of corrupted memory after sigsegv is boloney.<br>
Otherwise the whole sigsegv idea is pointless (you could just as well<br>
get terminated right away).</blockquote><div><br></div><div>The problem is that there's no guarantee that you *only* wrote outside your allocated virtual memory. You could have a bad pointer, overwrite half your program's data, then hit an invalid address and segfault. There are many scenarios in which bad writes *don't* cause segfaults (they may be incorrect, but they're still legal), so you can't really assume much about your program's state when you segfault. </div>

</div>