Null references redux

[grauzone]

Jeremie Pelletier wrote:
> downs wrote:
>> 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?
> 
> Not yet, its part of a custom runtime I'm working on and wish to release 
> under a public domain license when I get the time. The code is linked 
> from a thread in D.announce.

Some of this functionality is also in Tango (SVN version). Signals are 
catched only to print a backtrace.