[Issue 8185] Pure functions and pointers

d-bugmail at puremagic.com d-bugmail at puremagic.com
Mon Jun 4 11:22:12 PDT 2012


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



--- Comment #48 from klickverbot <code at 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: -------


More information about the Digitalmars-d-bugs mailing list