<div class="gmail_quote">On Mon, Oct 17, 2011 at 12:37 AM, Andrew Wiley <span dir="ltr"><<a href="mailto:wiley.andrew.j@gmail.com">wiley.andrew.j@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

<div class="gmail_quote"><div class="im">On Sun, Oct 16, 2011 at 11:54 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor.f.gyolchanyan@gmail.com" target="_blank">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><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></blockquote><div><br></div><div>Also: </div></div>On Sun, Oct 16, 2011 at 11:54 PM, Gor Gyolchanyan <span dir="ltr"><<a href="mailto:gor.f.gyolchanyan@gmail.com" target="_blank">gor.f.gyolchanyan@gmail.com</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: 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></blockquote><div><br></div><div>But you'll still get a segv. Read on.</div><div> </div>

<blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

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></blockquote><div><br></div><div>It doesn't depend on the implementation. A virtual memory system that allows one process to write to another process's memory is worthless in many respects (not quite all, but still).</div>

<div>A segv doesn't occur because you tried to write to the wrong place, it happens when you try to write to a virtual address that hasn't been mapped into your process's address space. Once a page is mapped in, the OS provides no safety against overwriting your own data by accident or overwriting malloc's data structures.</div>

<div>So yes, it doesn't just make no sense to throw the exception after the write, it's impossible. Where would the write go in physical memory? If there's no virtual page -> physical page mapping, that question can't be answered (hence the segfault).</div>

<div> </div><blockquote class="gmail_quote" style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0.8ex; border-left-width: 1px; border-left-color: rgb(204, 204, 204); border-left-style: solid; padding-left: 1ex; ">

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>sigsegv isn't really designed explicitly to catch your program when things go wrong, it's designed to handle what happens when your program asks the hardware/OS to do something it can't possibly do. It generally works because most of the virtual address space will generally be unmapped, but the reason things like SafeD and languages designed around the absence of pointers exist is that you can silently break things in subtle ways with pointers and not find out immediately what's going wrong.</div>