www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - What's the D equivalence?

reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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
Mar 05
next sibling parent reply Jacob Carlborg <doob me.com> writes:
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
Mar 05
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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.
Mar 05
parent reply Paul Backus <snarwin gmail.com> writes:
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.
Mar 05
next sibling parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
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.
Mar 05
prev sibling parent reply tsbockman <thomas.bockman gmail.com> writes:
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.
Mar 05
parent reply Nick Treleaven <nick geany.org> writes:
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).
Mar 06
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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? 🤔
Mar 06
parent reply Nick Treleaven <nick geany.org> writes:
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).
Mar 06
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
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 example.
Mar 06
parent reply Nick Treleaven <nick geany.org> writes:
On Saturday, 6 March 2021 at 14:44:36 UTC, Imperatorn wrote:
 I'm used to just doing it manually when needed, just like I 

 example.
How do you remember if a function handles null or not? E.g. for class references: c = new C; f(c); // did this modify c by `ref` parameter? // <<< do I need to check null here? g(c);
Mar 06
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Saturday, 6 March 2021 at 16:30:04 UTC, Nick Treleaven wrote:
 On Saturday, 6 March 2021 at 14:44:36 UTC, Imperatorn wrote:
 I'm used to just doing it manually when needed, just like I 

 example.
How do you remember if a function handles null or not? E.g. for class references: c = new C; f(c); // did this modify c by `ref` parameter? // <<< do I need to check null here? g(c);
tho. But I guess I'd do smth similar in D.
Mar 06
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 3/5/2021 2:13 AM, 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
Microsoft should have read this first: https://www.digitalmars.com/articles/C-biggest-mistake.html which is a far simpler scheme to do the same thing.
Mar 06
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 7 March 2021 at 01:20:07 UTC, Walter Bright wrote:
 On 3/5/2021 2:13 AM, 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
Microsoft should have read this first: https://www.digitalmars.com/articles/C-biggest-mistake.html which is a far simpler scheme to do the same thing.
True. I'm really impressed with your work on D, I just really don't understand why it isn't used more. But, I think we have a slight upward trend. I've been compiling (no pun intended?) some stats from github, FB, Twitter, Reddit, Discord (activity, users etc) and I think I have evidence for a slight organic growth. It's 2021, it's about time.
Mar 07