safety: null checks
snarwin at gmail.com
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" :
> 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
More information about the Digitalmars-d