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
