Jeremie Pelletier wrote: > Andrei Alexandrescu wrote: >> downs wrote: >>> Walter Bright wrote: >>>> Nick Sabalausky wrote: >>>> >>>> I agree with you that if the compiler can detect null dereferences at >>>> compile time, it should. >>>> >>>> >>>>>> Also, by "safe" I presume you mean "memory safe" which means free of >>>>>> memory corruption. Null pointer exceptions are memory safe. A null >>>>>> pointer could be caused by memory corruption, but it cannot *cause* >>>>>> memory corruption. >>>>> No, he's using the real meaning of "safe", not the >>>>> misleadingly-limited "SafeD" version of "safe" (which I'm still >>>>> convinced is going to get some poor soul into serious trouble from >>>>> mistakingly thinking their SafeD program is much safer than it really >>>>> is). Out here in reality, "safe" also means a lack of ability to >>>>> crash, or at least some level of protection against it. >>>> Memory safety is something that can be guaranteed (presuming the >>>> compiler is correctly implemented). There is no way to guarantee that a >>>> non-trivial program cannot crash. It's the old halting problem. >>>> >>> >>> Okay, I'm gonna have to call you out on this one because it's simply >>> incorrect. >>> >>> The halting problem deals with a valid program state - halting. >>> >>> We cannot check if every program halts because halting is an >>> instruction that must be allowed at almost any point in the program. >>> >>> Why do crashes have to be allowed? They're not an allowed instruction! >>> >>> A compiler can be turing complete and still not allow crashes. There >>> is nothing wrong with this, and it has *nothing* to do with the >>> halting problem. >>> >>>>> You seem to be under the impression that nothing can be made >>>>> uncrashable without introducing the possibility of corrupted state. >>>>> That's hogwash. >>>> I read that statement several times and I still don't understand >>>> what it >>>> means. >>>> >>>> BTW, hardware null pointer checking is a safety feature, just like >>>> array >>>> bounds checking is. >>> >>> PS: You can't convert segfaults into exceptions under Linux, as far >>> as I know. >> >> How did Jeremie do that? >> >> Andrei > > A signal handler with the undocumented kernel parameters attaches the > signal context to the exception object, repairs the stack frame forged > by the kernel to make us believe we called the handler ourselves, does a > backtrace right away and attaches it to the exception object, and then > throw it. > > The error handling code will unwind down to the runtime's main() where a > catch clause is waiting for any Throwables, sending them back into the > unhandled exception handler, and a crash window appears with the > backtrace, all finally blocks executed, and gracefully shutting down. > > All I need to do is an ELF/DWARF reader to extract symbolic debug info > under linux, its already working for PE/CodeView on windows. > > Jeremie
Woah, nice. I stand corrected. Is this in druntime already?