http://d.puremagic.com/issues/show_bug.cgi?id=8185



--- Comment #48 from klickverbot <c...@klickverbot.at> 2012-06-04 11:24:10 PDT 
---
(In reply to comment #46)
> (In reply to comment #45)
> > If a @trusted function accepts a pointer, it must _under no circumstances_
> > access anything except for the pointer target, because it can be called from
> > @safe code.
> 
> The point of @trusted is that it is treated as @safe, but can do unsafe 
> things.
>  At that point, you are telling the compiler that you know better than it does
> that the code is safe.
> 
> The compiler is going to assume you did not access anything else beyond the
> target, so you have to keep that in mind when writing a @trusted function that
> accepts a pointer parameter.
> 
> Off the top of my head, I can't think of any valid usage of this, but it
> doesn't mean we should necessarily put a restriction on @trusted functions. 
> This is a systems language, and @trusted is a tool used to circumvent @safe-ty
> when you know it is actually @safe.

Sorry, but I think you got this wrong. Consider this example:

---
void gun(int* a) @trusted;

int fun() @safe {
  auto val = new int;
  gun(val);
  return *val;
}
---

Here, calling gun needs to be safe under _any_ circumstances. Thus, the only
memory location which gun is allowed to access is val. If it does so by
evaluating *(a + k), where k = (catalanNumber(5) - meaningOfLife()), that's
fine, it's @trusted, but ultimately k must always be zero. Otherwise, it might
violate the memory safety guarantees that need to hold for fun(). This is
definitely not �defined by the programmer, and not expressed in possible way to
the type system or the compiler�.

Makes sense?

-- 
Configure issuemail: http://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

Reply via email to