Thread overview | ||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
March 05, 2021 What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
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 |
March 05, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Imperatorn | 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
|
March 05, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to 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.
|
March 05, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Imperatorn | 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.
|
March 05, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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.
|
March 05, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Paul Backus | 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.
|
March 06, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to tsbockman | 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).
|
March 06, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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? 🤔
|
March 06, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Imperatorn | 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).
|
March 06, 2021 Re: What's the D equivalence? | ||||
---|---|---|---|---|
| ||||
Posted in reply to Nick Treleaven | 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.
|
Copyright © 1999-2021 by the D Language Foundation