digitalmars.D - What's the D equivalence?
- Imperatorn (3/3) Mar 05 2021 As the title says, some of the things I know right away D already
- Jacob Carlborg (7/10) Mar 05 2021 One thing that is missing in D is runtime error on dereferencing
- Imperatorn (2/13) Mar 05 2021 Ok, that's fine though imo.
- Paul Backus (5/21) Mar 05 2021 It's actually a bit problematic because @safe relies on the fact
- Imperatorn (3/22) Mar 05 2021 Yeah, what I meant was, I'm so used to null-checking so it's not
- tsbockman (8/24) Mar 05 2021 Also, the guard region is of finite size and can be bypassed to
- Nick Treleaven (21/28) Mar 06 2021 Yes, and due to `ref` it can occur even when it looks like a null
- Imperatorn (2/24) Mar 06 2021 To summarize, am I safe if I always null check? 🤔
- Nick Treleaven (4/14) Mar 06 2021 How do you ensure every pointer dereference is guarded by a null
- Imperatorn (4/20) Mar 06 2021 I'm used to just doing it manually when needed, just like I
- Nick Treleaven (7/10) Mar 06 2021 How do you remember if a function handles null or not? E.g. for
- Imperatorn (3/13) Mar 06 2021 I basically just follow some purity rules. I'm talking C# now
- Walter Bright (4/8) Mar 06 2021 Microsoft should have read this first:
- Imperatorn (8/16) Mar 07 2021 True. I'm really impressed with your work on D, I just really
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 2021
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-overviewOne 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 2021
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:Ok, that's fine though imo.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-overviewOne 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 2021
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: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 10:13:32 UTC, Imperatorn wrote:Ok, that's fine though imo.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-overviewOne 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 2021
Imperatorn <johan_forsberg_86 hotmail.com> 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: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 13:09:26 UTC, Jacob Carlborg wrote: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 10:13:32 UTC, Imperatorn wrote:Ok, that's fine though imo.[...]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 2021
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: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 13:09:26 UTC, Jacob Carlborg wrote: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.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 CarlborgOk, that's fine though imo.
Mar 05 2021
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 2021
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:To summarize, am I safe if I always null check? 🤔[...]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 2021
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: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).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 2021
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:I'm used to just doing it manually when needed, just like I example.On Saturday, 6 March 2021 at 11:48:37 UTC, Nick Treleaven wrote: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).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 2021
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 2021
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:tho. But I guess I'd do smth similar in D.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 2021
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-overviewMicrosoft 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 2021
On Sunday, 7 March 2021 at 01:20:07 UTC, Walter Bright wrote:On 3/5/2021 2:13 AM, Imperatorn wrote: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.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-overviewMicrosoft 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 07 2021