www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.announce - Blog Post: What Does Memory Safety Really Mean in D?

reply Paul Backus <snarwin gmail.com> writes:
https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html

What exactly do we mean when we talk about "memory safety" in D? 
Is it the same thing as "undefined behavior"? Is it ever correct 
to mark and `extern(C)` function as ` trusted`? This post is my 
attempt to understand, and answer, questions like these.

If you think I've gotten anything wrong, please leave a 
reply--this is definitely an area where I'm still learning.
Aug 23
next sibling parent reply Paul Backus <snarwin gmail.com> writes:
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
 https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html
Oops, wrong link. Here's the correct one: https://pbackus.github.io/blog/what-does-memory-safety-really-mean-in-d.html
Aug 23
parent ag0aep6g <anonymous example.com> writes:
On Sunday, 23 August 2020 at 19:40:57 UTC, Paul Backus wrote:
 https://pbackus.github.io/blog/what-does-memory-safety-really-mean-in-d.html
As far as I can tell, your understanding matches mine. Hopefully, that's a good thing. I also agree that the "Memory Safety" page [1] isn't very helpful if you want to figure out what exactly "safety" means in D. It's more of a rough outline than a spec document. I consider the "Function Safety" section [2] (which you mention later) to be the real deal. If anyone wants to merge those two somewhat redundant pieces of the spec into one, that would be great. [1] https://dlang.org/spec/memory-safe-d.html [2] https://dlang.org/spec/function.html#function-safety
Aug 23
prev sibling next sibling parent reply Dukc <ajieskola gmail.com> writes:
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
 https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html

 What exactly do we mean when we talk about "memory safety" in 
 D? Is it the same thing as "undefined behavior"? Is it ever 
 correct to mark and `extern(C)` function as ` trusted`? This 
 post is my attempt to understand, and answer, questions like 
 these.

 If you think I've gotten anything wrong, please leave a 
 reply--this is definitely an area where I'm still learning.
Good post. I think there is a workaround to the variable access being always safe. Something like this in a dedicated module: ``` struct SystemVar(T, bool safeVal) { private T _var; static if (safeVal) safe pure nothrow nogc auto val() { return _var; } else pure nothrow nogc auto val(){return _var;} pure nothrow nogc ref var(){return _var;} } ```
Aug 26
next sibling parent Steven Schveighoffer <schveiguy gmail.com> writes:
On 8/26/20 10:29 AM, Dukc wrote:
 On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
 https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html

 What exactly do we mean when we talk about "memory safety" in D? Is it 
 the same thing as "undefined behavior"? Is it ever correct to mark and 
 `extern(C)` function as ` trusted`? This post is my attempt to 
 understand, and answer, questions like these.

 If you think I've gotten anything wrong, please leave a reply--this is 
 definitely an area where I'm still learning.
Good post. I think there is a workaround to the variable access being always safe. Something like this in a dedicated module: ``` struct SystemVar(T, bool safeVal) {  private T _var;    static if (safeVal) safe pure nothrow nogc auto val()    {  return _var;    }    else pure nothrow nogc auto val(){return _var;}    pure nothrow nogc ref var(){return _var;} } ```
Nice idea. You need to mark everything as system that should be -- this is a template, so the compiler is going to happily mark a lot (all?) of that as safe. -Steve
Aug 26
prev sibling parent reply Dennis <dkorpel gmail.com> writes:
On Wednesday, 26 August 2020 at 14:29:46 UTC, Dukc wrote:
 I think there is a workaround to the variable access being 
 always safe. Something like this in a dedicated module:

 ```
 struct SystemVar(T, bool safeVal)
 {  private T _var;
    static if (safeVal)  safe pure nothrow  nogc auto val()
    {  return _var;
    }
    else pure nothrow  nogc auto val(){return _var;}
    pure nothrow  nogc ref var(){return _var;}
 }
 ```
This currently does not protect against: - SystemVar.tupleof[0] (unless you have -preview=dip1000 set) - __traits(getMember, SystemVar, "_var") - aliasing (put SystemVar!int in a union with a plain int / cast SystemVar!int[] from int[]) - void initialization
Aug 26
parent reply Paul Backus <snarwin gmail.com> writes:
On Wednesday, 26 August 2020 at 15:34:26 UTC, Dennis wrote:
 On Wednesday, 26 August 2020 at 14:29:46 UTC, Dukc wrote:
 I think there is a workaround to the variable access being 
 always safe. Something like this in a dedicated module:

 ```
 struct SystemVar(T, bool safeVal)
 {  private T _var;
    static if (safeVal)  safe pure nothrow  nogc auto val()
    {  return _var;
    }
    else pure nothrow  nogc auto val(){return _var;}
    pure nothrow  nogc ref var(){return _var;}
 }
 ```
This currently does not protect against: - SystemVar.tupleof[0] (unless you have -preview=dip1000 set) - __traits(getMember, SystemVar, "_var") - aliasing (put SystemVar!int in a union with a plain int / cast SystemVar!int[] from int[]) - void initialization
Of course, you could also argue that these are things that shouldn't be allowed in safe code to begin with--regardless of whether pointers are involved. I think presenting system variables as "protection" against memory corruption is the wrong way frame the discussion. The problem is that, currently, it is only possible to provide safe access to certain kinds of data (discriminated unions, ref-counted pointers, etc.) by having trusted code make assumptions about safe code that must be manually verified. There is, technically, nothing wrong with this. The D language spec does not place any restrictions on what assumptions you are allowed to make in trusted code; it merely requires that you do the legwork to manually verify those assumptions if you want the compiler's automatic verification of safe code to give the correct result. What system variables do is allow you to document, in machine-readable form, a particular kind of assumption ("this variable is never accessed directly from safe code"), and have the compiler check it for you. In other words, they make trusted code more *expressive* and *ergonomic*.
Aug 27
parent reply Dennis <dkorpel gmail.com> writes:
On Thursday, 27 August 2020 at 13:32:44 UTC, Paul Backus wrote:
 Of course, you could also argue that these are things that 
 shouldn't be allowed in  safe code to begin with--regardless of 
 whether pointers are involved.
I did not intend to argue anything with that post, I was just pointing out the limitations of the workaround if it were used today, in case Dukc wasn't aware of them.
 I think presenting  system variables as "protection" against 
 memory corruption is the wrong way frame the discussion.
Is that still in reply to me (or DIP1035)? I don't recall saying something like that and don't want to get the wrong message across. I agree with everything you just wrote.
Aug 27
parent Paul Backus <snarwin gmail.com> writes:
On Thursday, 27 August 2020 at 14:10:36 UTC, Dennis wrote:
 On Thursday, 27 August 2020 at 13:32:44 UTC, Paul Backus wrote:
 Of course, you could also argue that these are things that 
 shouldn't be allowed in  safe code to begin with--regardless 
 of whether pointers are involved.
I did not intend to argue anything with that post, I was just pointing out the limitations of the workaround if it were used today, in case Dukc wasn't aware of them.
 I think presenting  system variables as "protection" against 
 memory corruption is the wrong way frame the discussion.
Is that still in reply to me (or DIP1035)? I don't recall saying something like that and don't want to get the wrong message across. I agree with everything you just wrote.
It was really a response to the discussion about DIP 1035 (and Andrei's critique in particular), using your post as an excuse to soapbox; apologies for the confusion.
Aug 27
prev sibling parent Atila Neves <atila.neves gmail.com> writes:
On Sunday, 23 August 2020 at 19:39:35 UTC, Paul Backus wrote:
 https://pbackus.github.io/blog/how-does-memory-safety-work-in-d.html

 What exactly do we mean when we talk about "memory safety" in 
 D? Is it the same thing as "undefined behavior"? Is it ever 
 correct to mark and `extern(C)` function as ` trusted`? This 
 post is my attempt to understand, and answer, questions like 
 these.

 If you think I've gotten anything wrong, please leave a 
 reply--this is definitely an area where I'm still learning.
Nice, thanks for the write-up. I've been owing the D community a blog post on memory safety for a few months now. I started writing it, then DIP1028 happened and I wanted to wait for a while to bring it up again.
Aug 27