On Friday, 29 May 2020 at 00:09:56 UTC, 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.
I think most C FFI should be @system, even if it's for popular libraries like SDL. Whenever you have API that takes a pointer and a size of array, you are risking buffer overflows and similar issues. It's very easy to mess up and send array length instead of array length * element.sizeof. A @trusted API would only accept a slice, which is much safer than raw pointers.
Alternatively you could just use @trusted blocks. Unsafe blocks are a common practice in languages like C# or Rust when it comes to calling unsafe code. @safe isn't about 100% bulletproof safety. @safe is (should be) about not having memory related errors outside of @trusted code, minimizing the surface area for errors.
