Determining @trusted-status

[ag0aep6g]

On 29.05.20 02:09, Clarice wrote:
> It seems that @safe will be de jure, whether by the current state of 
> DIP1028 or otherwise. However, I'm unsure how to responsibly determine 
> whether a FFI may be @trusted: the type signature and the body. Should I 
> run, for example, a C library through valgrind to observe any memory 
> leaks/corruption? Is it enough to trust the authors of a library (e.g. 
> SDL and OpenAL) where applying @trusted is acceptable?
> There's probably no one right answer, but I'd be very thankful for some 
> clarity, regardless.

There are two ways in which a function can be unsafe:

1) The function has a bug and doesn't behave as intended.
2) The function doesn't have a safe interface [1].

When applying @trusted, you are allowed to pretend that #1 doesn't 
happen. You are allowed to trust that the author of the library made no 
safety-critical mistakes.

What you have to look out for is #2. When a function has special 
requirements for how to call it, and calling it incorrectly can lead to 
undefined behavior / memory corruption, then it cannot be @trusted. It 
can only be @system. In order to use the function in @safe code, you 
need to write an @trusted wrapper that provides a safe interface and 
makes sure that the @system function is called correctly.


[1] https://dlang.org/spec/function.html#safe-interfaces