import core.stdc.stdio : printf;

extern (C++) abstract class A {
    void sayHello();
}

extern (C++) class B : A {
    override void sayHello() {
        printf("hello\n");
    }
}

extern (C) void main() {
    //scope b = new B;
    B b;
    assert(b);
    b.sayHello();
}


Above fails because b is null. But why doesn't the compiler say so? It seems like a very basic safety check.

On Sunday, 22 November 2020 at 11:52:13 UTC, Dibyendu Majumdar wrote:
> Above fails because b is null. But why doesn't the compiler say so? It seems like a very basic safety check.

Nullpointer exceptions aren't a safety issue since the program crashes. For it to be a safety issue, it would need to have "bad consequences" e.g. writes to memory at locations the program isn't supposed to.

On Sunday, 22 November 2020 at 15:25:48 UTC, Q. Schroll wrote:
> On Sunday, 22 November 2020 at 11:52:13 UTC, Dibyendu Majumdar wrote:
>> Above fails because b is null. But why doesn't the compiler say so? It seems like a very basic safety check.
>
> Nullpointer exceptions aren't a safety issue since the program crashes. For it to be a safety issue, it would need to have "bad consequences" e.g. writes to memory at locations the program isn't supposed to.

Right. A crash isn't a bad consequence, of course.

On Sunday, 22 November 2020 at 22:16:11 UTC, Dibyendu Majumdar wrote:
> On Sunday, 22 November 2020 at 15:25:48 UTC, Q. Schroll wrote:
>> On Sunday, 22 November 2020 at 11:52:13 UTC, Dibyendu Majumdar wrote:
>>> Above fails because b is null. But why doesn't the compiler say so? It seems like a very basic safety check.
>>
>> Nullpointer exceptions aren't a safety issue since the program crashes. For it to be a safety issue, it would need to have "bad consequences" e.g. writes to memory at locations the program isn't supposed to.
>
> Right. A crash isn't a bad consequence, of course.

Memory safety is concerned specifically with avoiding undefined behavior. Crashing the program isn't undefined behavior, so it's allowed in @safe code.

On Sunday, 22 November 2020 at 22:36:40 UTC, Paul Backus wrote:
> Memory safety is concerned specifically with avoiding undefined behavior. Crashing the program isn't undefined behavior, so it's allowed in @safe code.

I understand what you mean, but at high optimization levels dereferencing a null pointer can trigger undefined behaviour.

On Sunday, 22 November 2020 at 23:00:25 UTC, Ola Fosheim Grostad wrote:
> On Sunday, 22 November 2020 at 22:36:40 UTC, Paul Backus wrote:
>> Memory safety is concerned specifically with avoiding undefined behavior. Crashing the program isn't undefined behavior, so it's allowed in @safe code.
>
> I understand what you mean, but at high optimization levels dereferencing a null pointer can trigger undefined behaviour.

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.

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...

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.

what spec? :)

On Sunday, 22 November 2020 at 23:46:23 UTC, Ola Fosheim Grostad wrote:
> 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.

[1] https://dlang.org/spec/function.html#safe-values

On Monday, 23 November 2020 at 00:17:12 UTC, Paul Backus wrote:

> 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.
>
> [1] https://dlang.org/spec/function.html#safe-values

Hmm, null values are not the same as dereferncing null values.
A null in itself is okay, but dereferencing null cannot be.