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.
