Null references redux

Yigal Chripun yigal100 at gmail.com
Sun Sep 27 11:43:08 PDT 2009


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?



More information about the Digitalmars-d mailing list