Null references redux

[Jeremie Pelletier]

Yigal Chripun wrote:
> On 27/09/2009 19:29, 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
> 
> Is this Linux specific? what about other *nix systems, like BSD and 
> solaris?

Signal handler are standard to most *nix platforms since they're part of 
the posix C standard libraries, maybe some platforms will require a 
special handling but nothing impossible to do.