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