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.

Reply via email to