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
