As the title says, some of the things I know right away D already has. But is there something checkedc has that we don't?

https://github.com/Microsoft/checkedc/wiki/Extension-overview

On Friday, 5 March 2021 at 10:13:32 UTC, Imperatorn wrote:
> As the title says, some of the things I know right away D already has. But is there something checkedc has that we don't?
>
> https://github.com/Microsoft/checkedc/wiki/Extension-overview

One thing that is missing in D is runtime error on dereferencing a null pointer. D relies on the platform to trigger a segmentation fault. Of course, there are some platforms that don't do that.

--
/Jacob Carlborg

On Friday, 5 March 2021 at 13:09:26 UTC, Jacob Carlborg wrote:
> On Friday, 5 March 2021 at 10:13:32 UTC, Imperatorn wrote:
>> As the title says, some of the things I know right away D already has. But is there something checkedc has that we don't?
>>
>> https://github.com/Microsoft/checkedc/wiki/Extension-overview
>
> One thing that is missing in D is runtime error on dereferencing a null pointer. D relies on the platform to trigger a segmentation fault. Of course, there are some platforms that don't do that.
>
> --
> /Jacob Carlborg

Ok, that's fine though imo.

On Friday, 5 March 2021 at 15:17:29 UTC, Imperatorn wrote:
> On Friday, 5 March 2021 at 13:09:26 UTC, Jacob Carlborg wrote:
>> On Friday, 5 March 2021 at 10:13:32 UTC, Imperatorn wrote:
>>> As the title says, some of the things I know right away D already has. But is there something checkedc has that we don't?
>>>
>>> https://github.com/Microsoft/checkedc/wiki/Extension-overview
>>
>> One thing that is missing in D is runtime error on dereferencing a null pointer. D relies on the platform to trigger a segmentation fault. Of course, there are some platforms that don't do that.
>>
>> --
>> /Jacob Carlborg
>
> Ok, that's fine though imo.

It's actually a bit problematic because @safe relies on the fact that dereferencing a null pointer has defined behavior (i.e., it crashes the program). On platforms that don't guarantee this, D currently allows undefined behavior in @safe code.

On Friday, 5 March 2021 at 15:22:51 UTC, Paul Backus wrote:
> On Friday, 5 March 2021 at 15:17:29 UTC, Imperatorn wrote:
>> On Friday, 5 March 2021 at 13:09:26 UTC, Jacob Carlborg wrote:
>>> On Friday, 5 March 2021 at 10:13:32 UTC, Imperatorn wrote:
>>>> [...]
>>>
>>> One thing that is missing in D is runtime error on dereferencing a null pointer. D relies on the platform to trigger a segmentation fault. Of course, there are some platforms that don't do that.
>>>
>>> --
>>> /Jacob Carlborg
>>
>> Ok, that's fine though imo.
>
> It's actually a bit problematic because @safe relies on the fact that dereferencing a null pointer has defined behavior (i.e., it crashes the program). On platforms that don't guarantee this, D currently allows undefined behavior in @safe code.

Yeah, what I meant was, I'm so used to null-checking so it's not a big deal for me.

On Friday, 5 March 2021 at 15:22:51 UTC, Paul Backus wrote:
> On Friday, 5 March 2021 at 15:17:29 UTC, Imperatorn wrote:
>> On Friday, 5 March 2021 at 13:09:26 UTC, Jacob Carlborg wrote:
>>> One thing that is missing in D is runtime error on dereferencing a null pointer. D relies on the platform to trigger a segmentation fault. Of course, there are some platforms that don't do that.
>>>
>>> --
>>> /Jacob Carlborg
>>
>> Ok, that's fine though imo.
>
> It's actually a bit problematic because @safe relies on the fact that dereferencing a null pointer has defined behavior (i.e., it crashes the program). On platforms that don't guarantee this, D currently allows undefined behavior in @safe code.

Also, the guard region is of finite size and can be bypassed to potentially silently corrupt memory when accessing the interior of a sufficiently large type:

void sowChaos(size_t length)(int[length]* ptr) @safe {
    (*ptr)[length - 1] = 0xBAD; }

If (int.sizeof * (length - 1)) happens to be the address of memory writable by the current process, this will do bad things.

On Friday, 5 March 2021 at 21:09:38 UTC, tsbockman wrote:
> Also, the guard region is of finite size and can be bypassed to potentially silently corrupt memory when accessing the interior of a sufficiently large type:
>
> void sowChaos(size_t length)(int[length]* ptr) @safe {
>     (*ptr)[length - 1] = 0xBAD; }
>
> If (int.sizeof * (length - 1)) happens to be the address of memory writable by the current process, this will do bad things.

Yes, and due to `ref` it can occur even when it looks like a null dereference should have happened:

@safe:

void f(ref BigFixedArr b)
{
	// ... complex logic
	b[b.length-1] = 4; // possible memory corruption even on null trapping systems
}
void main()
{
	BigFixedArr* p;
	// ... complex logic
	f(*p); // at least if p is accidentally null, it will crash here, right? nope
}

This could be fixed by checking for null in @safe code when dereferencing a pointer passed to a `ref` parameter. But that doesn't fix the unsafety of the sowChaos example (although at least that isn't so confusing).

On Saturday, 6 March 2021 at 11:48:37 UTC, Nick Treleaven wrote:
> On Friday, 5 March 2021 at 21:09:38 UTC, tsbockman wrote:
>> [...]
>
> Yes, and due to `ref` it can occur even when it looks like a null dereference should have happened:
>
> @safe:
>
> void f(ref BigFixedArr b)
> {
> 	// ... complex logic
> 	b[b.length-1] = 4; // possible memory corruption even on null trapping systems
> }
> void main()
> {
> 	BigFixedArr* p;
> 	// ... complex logic
> 	f(*p); // at least if p is accidentally null, it will crash here, right? nope
> }
>
> This could be fixed by checking for null in @safe code when dereferencing a pointer passed to a `ref` parameter. But that doesn't fix the unsafety of the sowChaos example (although at least that isn't so confusing).

To summarize, am I safe if I always null check? 🤔

On Saturday, 6 March 2021 at 11:52:41 UTC, Imperatorn wrote:
> On Saturday, 6 March 2021 at 11:48:37 UTC, Nick Treleaven wrote:
>> 	f(*p); // at least if p is accidentally null, it will crash here, right? nope
>> }
>>
>> This could be fixed by checking for null in @safe code when dereferencing a pointer passed to a `ref` parameter. But that doesn't fix the unsafety of the sowChaos example (although at least that isn't so confusing).
>
> To summarize, am I safe if I always null check? 🤔

How do you ensure every pointer dereference is guarded by a null check? I think you would need a tool to ensure that (or insert the checks for you).

On Saturday, 6 March 2021 at 12:15:16 UTC, Nick Treleaven wrote:
> On Saturday, 6 March 2021 at 11:52:41 UTC, Imperatorn wrote:
>> On Saturday, 6 March 2021 at 11:48:37 UTC, Nick Treleaven wrote:
>>> 	f(*p); // at least if p is accidentally null, it will crash here, right? nope
>>> }
>>>
>>> This could be fixed by checking for null in @safe code when dereferencing a pointer passed to a `ref` parameter. But that doesn't fix the unsafety of the sowChaos example (although at least that isn't so confusing).
>>
>> To summarize, am I safe if I always null check? 🤔
>
> How do you ensure every pointer dereference is guarded by a null check? I think you would need a tool to ensure that (or insert the checks for you).

I'm used to just doing it manually when needed, just like I null-check my objects in c# before accessing some property for example.