Jump to page: 1 24  
Page
Thread overview
safety: null checks
3 days ago
Q. Schroll
2 days ago
Paul Backus
2 days ago
Paul Backus
2 days ago
Paul Backus
2 days ago
Paul Backus
2 days ago
Paul Backus
2 days ago
ag0aep6g
2 days ago
Paul Backus
2 days ago
ag0aep6g
2 days ago
Johan Engelen
2 days ago
Paul Backus
2 days ago
Johan Engelen
2 days ago
Paul Backus
2 days ago
Max Haughton
2 days ago
Adam D. Ruppe
3 days ago
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.
3 days ago
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.
2 days ago
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.



2 days ago
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.
2 days ago
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.
2 days ago
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.
2 days ago
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...
2 days ago
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? :)
2 days ago
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


2 days ago
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.
« First   ‹ Prev
1 2 3 4