Determining @trusted-status

[JN]

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.