Fantastic exchange from DConf

Fri May 19 13:19:46 PDT 2017

On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes Scherkl 
wrote:
> On Friday, 19 May 2017 at 15:52:52 UTC, Moritz Maxeiner wrote:
>> On Friday, 19 May 2017 at 15:12:20 UTC, Steven Schveighoffer
>>> I don't expect people to use Phobos and audit all the 
>>> @trusted blocks personally.
>>
>> As long as they don't actually call them, that's reasonable. 
>> But if your application ends up calling @trusted code and you 
>> did not audit that @trusted yourself, you have violated the 
>> @trusted requirement:
>> You cannot promise to the compiler that the code is memory 
>> safe since you have no knowledge of what it actually does.
> No. @trusted is about trust: you cannot rely on the compiler to 
> verify it, but the code is reviewed by humans.

Precisely. It is about trust the compiler extends to you, the 
programmer, instead of a mechanical proof (@safe):

"Trusted functions are guaranteed by the programmer to not 
exhibit any undefined behavior if called by a safe function. 
Generally, trusted functions should be kept small so that they 
are easier to manually verify." [1]

If you write an application that uses @trusted code - even from a 
third party library - *you* are the programmer that the compiler 
extends the trust to.

> So there is a  list of reviewers and if this list contains some 
> names you happen to trust (sic!) you don't have to audit the 
> code yourself.

Trust, but verify: Considering the damages already caused via 
memory corruption, I would argue that even if you have a list of 
people you trust to both write @trusted and review @trusted code 
(both of which is fine imho), reviewing them yourself (when 
writing an application) is the prudent (and sane) course of 
action.

> Especially basic libraries will over time become tested and 
> audited by very many people or even organizations. So after 
> some time they really can be trusted.

Absolutely not. This kind of mentality is what allowed bugs like 
heartbleed to rot for years[2], or even decades[3]. Unsafe code 
can never be *inherently* trusted.

>
>>> If "D is  memory safe" means "D is memory safe ONLY if you 
>>> verify all of the standard library personally", we still have 
>>> lost.
>>
>> It is more like "D is memory safe" meaning "D is memory safe 
>> ONLY if you verify all of the @trusted code your application 
>> end up compiling in / linking against".
>> There is no way around that I can see without getting rid of 
>> @trusted, which is impossible for a systems PL.
> For bigger projects you always need to trust in some previous 
> work.

Not really. You can always verify any @trusted code (and if the 
amount of @trusted code you have to verify is large, then I argue 
that you are using the wrong previous work with regards to memory 
safety).

> But having the @trusted and @save mechanism makes the resulting 
> code a whole lot more trustworthy than any C library can ever 
> be - just by reducing the number of lines of code that really 
> need be audited.

I agree with that viewpoint (and wrote about the reduced auditing 
work previously in this conversation), but the quote you 
responded to here was about using D in general being memory safe 
(which is binary "yes/no"), not any particular library's degree 
of trustworthyness with regards to memory safety (which is a 
continuous scale).

> I personally would not going bejond probing some few functions 
> within a library which I think are more complicated and 
> fragile, and if I find them ok, my trust in what else the 
> authors have marked @trusted increases likewise.

That is your choice, but the general track record of trusting 
others to get it right without verifying it yourself remains 
atrocious and I would still consider you negligent for doing so, 
because while in C one has had little other choice historically - 
since without a @safe concept the amount of code one would have 
to verify reaches gargantuan size - in D we can (and should imho) 
only have small amounts of @trusted code.

[1] https://dlang.org/spec/function.html#trusted-functions
[2] 
https://www.theguardian.com/technology/2014/apr/11/heartbleed-developer-error-regrets-oversight
[3] 
https://www.theguardian.com/technology/2014/jun/06/heartbleed-openssl-bug-security-vulnerabilities