Simplification of @trusted

Ola Fosheim Grøstad ola.fosheim.grostad at gmail.com
Thu Jun 17 21:37:04 UTC 2021


On Thursday, 17 June 2021 at 21:00:13 UTC, Paul Backus wrote:
> A lot of people on the D forums have an incomplete or incorrect 
> understanding of what memory safety means, and how D's @safe, 
> @trusted and @system attributes can be used to help prove a 
> program memory-safe. The interpretation that I and ag0aep6g 
> have been describing is the correct one.

There is a difference between proving a program memory safe and 
having to assume that all @safe code is maximally broken. Which 
is what is required here.

Also, ag0aep6g are not happy with proving that the class is 
memory safe. It has to be memory safe when non-pointer values are 
overwritten with garbage. He wants you to look at each @trusted 
method in isolation, not the class as a whole.

> Re: interfacing with C, the best guarantee you can reasonably 
> hope to achieve is "my @trusted code is memory safe as long as 
> the C functions I'm calling behave as specified in the relevant 
> documentation or standard."

More tricky that that I think. If I obtain a DOM node from a C 
library, then that DOM node points to the parent node, and so on, 
effectively I could have the entire C heap in my hands.

You basically either have to create slow wrappers around 
everything or manually modify the C-bindings so you give less 
information to the D compiler than the C compiler has (basically 
censor out back pointers from the struct)??

Or maybe not. Either way, it is not trivial to reason about the 
consequences that you get from obtaining not just objects from 
C-code, but nodes in a connected graph.

I haven't tried to create such safe bindings, maybe I am wrong. 
Maybe there are some easy patterns one can follow.





More information about the Digitalmars-d mailing list