On Friday, 19 May 2017 at 11:53:57 UTC, Steven Schveighoffer
wrote:
On 5/19/17 5:12 AM, Moritz Maxeiner wrote:
On Thursday, 18 May 2017 at 12:12:18 UTC, Steven Schveighoffer
wrote:
[...]
We still allow unsafe operations inside @safe code, using
@trusted.
This is a necessary evil, but it's so very important that the
base
libraries (druntime and phobos) keep this to a minimum, and
that we
review those @trusted blocks to death.
That and we need to make sure it is understood by everyone
using third
party @safe code that it is *not* a "I don't have to audit
this code"
free card. It merely reduced the amount of code you need to
review to
what is marked as @trusted (with regards to memory safety); as
long as
you don't *know* whether some third party code is @safe or
@trusted, you
(as the programmer) have to assume it is @trusted and that
means you
have to extend trust to the author and cannot assume any of
the @safe
guarantees for that code.
What we need are 2 things:
1. @trusted blocks need to be rock-solid in Phobos and
Druntime. And as rare as possible.
Agreed 100%.
This provides a foundation to build completely @safe libraries.
Agreed if you mean libraries being marked completely as @safe
(which I assume).
Disagreed if you mean libraries that are proven to never corrupt
memory (not possible with unsafe operating system).
It's like atomics -- they are hugely important and very easy to
get wrong.
Sure.
Leave the actual implementation to the pros.
If you mean the act of implementing: Yes, agreed.
If you mean the entire mind space of the implementation, aka you
(the programmer) receives a "get out of audit this" free card,
because "professionals" wrote it: No. You are *always*
responsible for verifying *all* third party @trusted code
*yourself*.
We should be the pros on phobos/druntime safety.
Agreed.
2. @trusted blocks in any project need to be considered red
flags. You should not need to audit @safe code.
Yes you do, because it can call into @trusted like this:
---
void foo(int[] bar) @safe
{
() @trusted {
// Exploitable code here
}();
}
---
You *must* audit third party @safe code for such hidden @trusted
code (e.g. grep recursively through such third party code for
@trusted and verify).
What you need to do is audit @trusted code when it interacts
with @safe code.
You need to audit *all* @trusted code, because you don't
necessarily control who calls it.
If you can prove that in *all cases* the @safe code is still
@safe even with the included @trusted blocks, then you don't
have to audit @safe code that calls that "tainted" function.
s/prove/promise/
But yes, that is precisely what I wrote in the above with regards
to the reduction of what you have to audit.
If we get into "@safe really means @trusted" territory, we have
lost.
For code that you write yourself, @safe means @safe, of course.
For code other people write and you want to call, it being marked
@safe does really mean @trusted as long as you yourself have not
looked inside it and verified there either is no hidden @trusted,
or verified *yourself* that the hidden @trusted is memory safe.
I consider any other behaviour to be negligent to the degree of
"you don't actually care about memory safety at all".
