On Friday, 19 May 2017 at 20:19:46 UTC, Moritz Maxeiner wrote:
On Friday, 19 May 2017 at 17:21:23 UTC, Dominikus Dittes
Scherkl wrote:
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]
I take this to mean the programmer who wrote the library, not
every user of the library. Ok, it's better the more people
checked it but it need not be always me.
Hm - we should have some mechanism to add to some list of people
who already trust the code because they checked it.
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.
This is not my point of view. Especially if I had payed for some
library, even legally it's not my fault if it fails. For public
domain ok, the end user is theoretically responsible for
everything that goes wrong but even there nobody can check
everything or even a relevant portion of it.
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.
This is infeasable even if @safe and @trusted reduce the Herculic
task by large.
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.
In addition to trusted, D has unittests that - in harsh contrast
to C - are run by most users. And especially @trusted functions
have extensive tests - even more so if they ever showed some
untrustworthy behaviour.
This increasing unittest blocks make older and more used
libraries indeed more reliable, even if a function is changed
(also in contrast to C where a changed function start again at
zero trust while a D function has to pass all the old unittests
and therefore start with high trust level)
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).
Sorry. Reviewing everything you use is impossible. I just can't
believe you if you claim to do so.
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).
No. Declaring a function @safe is still no binary "yes". I don't
believe in such absolute values. Clearly the likelyhood of memory
corruption will be orders of magnitude lower, but never zero. The
compiler may have bugs, the system a SW is running on will have
bugs, even hardware failures are possible. Everything is about
trust.
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.
Of course. And an decreasing amount. But what we have is already
a huge step in the right direction.
We should live in the reality. Everybodies time is spare. So you
can always spent your time for checking code only for the parts
which are most important for you and which you suspect the most.
Claiming otherwise is - believe it or not - making you less
trustworthy to me.
