On 2/24/15 5:37 PM, "Ola Fosheim =?UTF-8?B?R3LDuHN0YWQi?=
<ola.fosheim.grostad+dl...@gmail.com>" wrote:
Since neither Andrei or Walter are able to say something sensible on
these issues when asked, I apparently need to learn something about the
"consistency" of C memory safety.
I'm happy to listen to anyone who can explain this to me:
1. My understanding is that @trusted is supposed to give memory safety
escapes by providing a context which reestablish a memory safety context
on return.
Yet in this thread
http://forum.dlang.org/thread/mcik3j$153g$1...@digitalmars.com it is stated
that this paradigm is an example of «careful use of @trusted»:
count = (() @trusted => cast(uint*) malloc(uint.sizeof))();
…arbitrary code…
(() @trusted => free(count))();
This isn't exactly what is happening.
First, malloc should be safe, in the same way new is safe. The fact that
@trusted is needed is somewhat incorrect in my opinion.
Where @trusted SHOULD be needed is for `free`.
Now, I disagree that using a @trusted delegate for the free is the right
thing to do. As soon as you free count, it is no longer safe, because
it's a dangling pointer.
I would say THIS is somewhat correct:
(() @trusted {free(count); count=null;})();
This takes something that is validly safe, and keeps the safety by
ensuring the pointer is no longer dangling.
However, we have an issue here. At any point inside the code, you could do:
oldcount = count;
And now, there is still potentially a dangling pointer somewhere. This
means every place count is used must be checked. In this case, all uses
of count have to be re-checked when the file is edited.
Because count leaks the memory details of the trusted call to free (In
other words, the fact that count, or any copy of it, can become a
dangling pointer), I believe every call in that type that deals with
count should be marked trusted.
This is a great example of why @trusted is mostly a convention thing,
and not an enforceable thing. And it's very difficult to get right.
There is no way to say "compiler, count is tainted. Please error
whenever anyone uses count without marking that code as @trusted."
They way I see it, this is equivalent to typing a reinterpret_casting
malloc and free as memorysafe operations in isolation, basically
providing a malloc!int() and free() as memory safe functions. But why is
malloc and free not considered safe by default then? These @trusted
functions clearly cannot prevent leaks within their own context. You
would need a @trusted-only storage class on the receiving pointer to do
that and a @trusted move type.
If this is careful use of @trusted, then I don't see the point of having
@trusted at all. What is the purpose? What is it meant to cover? In
order for @trusted to make sense in this code segment (
http://dpaste.dzfl.pl/f3d854feede9 ) I would say that the whole class
will have to be marked @trusted. Is that possible?
I agree. I think it's possible, like this:
struct RCArray(E) {
@trusted:
But it doesn't help with mechanical checking -- @trusted is still
basically more dangerous @system code.
-Steve
