safety: null checks

Paul Backus snarwin at
Mon Nov 23 00:17:12 UTC 2020

On Sunday, 22 November 2020 at 23:46:23 UTC, Ola Fosheim Grostad 
> On Sunday, 22 November 2020 at 23:28:26 UTC, Paul Backus wrote:
>> Then that's a bug in the compiler. A @safe D program is 
>> allowed to dereference null, so a spec-conformant D compiler 
>> *must* ensure that dereferencing null has defined behavior.
> Where does it say that? This won't work on embedded platforms.
> Not being allowed to reject buggy code would be bad...

Ok, technically, a spec-confirming D implementation must either 
guarantee that dereferencing null has defined behavior, *or* 
forbid default initialization of pointers in @safe code.

The relevant part of the spec is the one on "safe values" [1]:

> A pointer is safe when:
>    1. it can be dereferenced validly [i.e. with defined 
> behavior], and
>    2. the value of the pointee is safe.

If null is a safe value, then dereferencing it must be defined 
behavior. If null is an unsafe value, then it must not be allowed 
to appear in @safe code. Either way, a compiler that allows null 
in @safe code but treats a null dereference as undefined behavior 
is buggy.


More information about the Digitalmars-d mailing list