On Friday, 19 May 2017 at 20:54:40 UTC, Dominikus Dittes Scherkl
wrote:
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.
I take this to mean any programmer that ends up compiling it (if
you use a precompiled version that you only link against that
would be different).
Hm - we should have some mechanism to add to some list of
people who already trust the code because they checked it.
Are you talking about inside the code itself?
If so, I imagine digitally signing the functions source code
(ignoring whitespace) and adding the signature to the docstring
would do 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.
It is mine, because even if you payed for the library, when you
compile it, the compiler cannot know where the library came from.
It only knows you (the programmer who invoked it), as the one it
extends trust to. I am specifically not talking about what is
legally your fault or not, because I consider that an entirely
different matter.
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.
That entirely depends on how much @trusted code you have.
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.
I disagree.
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)
Those are valuable tools, but they do not make any piece of code
*inherently* trustworthy.
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.
I specifically stated reviewing any @trusted code, not all code.
And so far I have made no claim about not being negligent myself
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).
No. Declaring a function @safe is still no binary "yes".
Again, this was not about any particular function (or library),
but about using D in general.
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 agree in principal, but the statement I responded to was "D is
memory safe", which either does or does not hold. I also believe
that considering the statement's truthfulness only makes sense
under the assumption that nothing *below* it violates that, since
the statement is about language theory.
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.
Yes, it is.
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.
Of course anyone can choose to check whatever they wish. That
does not change what *I* consider negligent.
Claiming otherwise is - believe it or not - making you less
trustworthy to me.
Where did I claim otherwise? Errare humanum est, sed in errare
perseverare diabolicum.
In this context: It is one thing to be negligent (and I
explicitly do not claim *not* to be negligent myself), but
something completely different to pretend that being negligent is
OK.