Why does nobody seem to think that `null` is a serious problem in D?

[Jonathan M Davis]

On Monday, November 19, 2018 5:30:00 PM MST Steven Schveighoffer via 
Digitalmars-d-learn wrote:
> On 11/19/18 7:21 PM, Jordi Gutiérrez Hermoso wrote:
> > On Monday, 19 November 2018 at 21:52:47 UTC, Steven Schveighoffer wrote:
> >> A null pointer dereference is an immediate error, and it's also a safe
> >> error. It does not cause corruption, and it is free (the MMU is doing
> >> it for you).
> >
> > Is this always true for all arches that D can compile to? I remember
> > back in the DOS days with no memory protection you really could read OS
> > data around the beginning.
>
> It's true for all OSes that D supports, and for most modern operating
> systems, that run in protected mode.
>
> It would NOT necessarily be true for kernel modules or an OS kernel, so
> that is something to be concerned about.

For @safe to function properly, dereferencing null _must_ be guaranteed to
be memory safe, and for dmd it is, since it will always segfault.
Unfortunately, as understand it, it is currently possible with ldc's
optimizer to run into trouble, since it'll do things like see that something
must be null and therefore assume that it must never be dereferenced, since
it would clearly be wrong to dereference it. And then when the code hits a
point where it _does_ try to dereference it, you get undefined behavior.
It's something that needs to be fixed in ldc, but based on discussions I had
with Johan at dconf this year about the issue, I suspect that the spec is
going to have to be updated to be very clear on how dereferencing null has
to be handled before the ldc guys do anything about it. As long as the
optimizer doesn't get involved everything is fine, but as great as
optimizers can be at making code faster, they aren't really written with
stuff like @safe in mind.

> >> Consistent segfaults are generally easy to figure out.
> >
> > I think I would still prefer a stack trace like other kinds of D errors.
> > Is this too difficult?
>
> Yes and no. It's good to remember that this is a HARDWARE generated
> exception, and each OS handles it differently. It's also important to
> remember that a segmentation fault is NOT necessarily the result of a
> simple error like forgetting to initialize a variable. It could be a
> serious memory corruption error. Generating stack traces can be
> dangerous in this kind of state.
>
> As I said, on Linux you can enable a "hack" that generates an error for
> a null dereference. On Windows, I believe that it already generates an
> exception without any modification.
>
> On other OSes you may be out of luck until someone figures out a nice
> clever hack for it.
>
> And if it's repeatable, you can always run in a debugger to see where
> the error is occurring.

Also, if your OS supports core dumps, and you have them turned on, then it's
trivial to get a stack trace - as well as a lot more of the program state.

- Jonathan M Davis