Null references redux

[downs]

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.