dip1000 and preview in combine to cause extra safety errors

[Paul Backus]

On Thursday, 9 June 2022 at 00:44:58 UTC, Ali Çehreli wrote:
> I was convinced (after having an email exchange with Walter) 
> that unless we assumed extern(C) functions @safe, then nobody 
> would bother marking their declarations as @trusted one-by-one. 
> And whoever marked them as such, they would do it without 
> actually auditing any source code.

It is actually even worse than this: no matter how diligent you 
are, it is impossible to audit the source code corresponding to 
an extern(C) function declaration, even in principle.

The reason for this is that when your code calls an extern(C) 
function, it is not calling a specific implementation. Rather, it 
is calling whatever implementation happens to get linked into the 
final binary when the code is compiled. If someone builds your 
code 10 years from now on a new system, it may end up calling a C 
implementation that was not even written yet when you wrote your 
extern(C) function declaration!

Strictly speaking, this means that you can *never* be absolutely, 
100% mathematically sure that an extern(C) function is 
memory-safe. So if you are aiming for an absolute, 100% 
mathematically-ironclad guarantee of memory safety, your program 
cannot call any extern(C) functions, ever, period.

Unfortunately, this also means your program cannot make any 
system calls, so you will probably not get very far attempting to 
program this way.

The solution is to give up on aiming for an absolute, 100% 
mathematical guarantee of memory safety under all possible 
circumstances. Instead, what we aim for in practice is a 
*conditional* guarantee: "my program is memory safe, so long as 
assumptions A, B, and C about the external world hold true."

Some common assumptions we make are:

* The OS's system call interface behaves as documented.
* The C standard library API behaves as specified in the relevant 
C standard.
* Other C libraries I depend on behave as documented.

It is important to understand that relying on C libraries to 
behave according to their documentation is *not* the same thing 
as marking their functions as @trusted. Many C library functions 
say explicitly, in their documentation, that they *will* corrupt 
memory if called in certain ways. These functions must still be 
marked as @system, even if you are willing to "trust" the 
libraries to behave as-documented.