Why does nobody seem to think that `null` is a serious problem in D?
Steven Schveighoffer
schveiguy at gmail.com
Tue Nov 20 00:30:00 UTC 2018
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.
>> 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.
-Steve
More information about the Digitalmars-d-learn
mailing list