Thread overview | |||||||||||||||||||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
November 22, 2020 safety: null checks | ||||
---|---|---|---|---|
| ||||
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. |
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dibyendu Majumdar | 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.
|
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Q. Schroll | 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.
|
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Dibyendu Majumdar | 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.
|
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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.
|
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | 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.
|
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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...
|
November 22, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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? :)
|
November 23, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Ola Fosheim Grostad | 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 |
November 23, 2020 Re: safety: null checks | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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.
|
Copyright © 1999-2021 by the D Language Foundation