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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020
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 2020