On Saturday, June 01, 2013 23:45:59 Maxim Fomin wrote:
> On Saturday, 1 June 2013 at 21:41:40 UTC, Jonathan M Davis wrote:
> > They're guaranteed to not introduce any such behavior. They
> > can't possibly
> > make any guarantees if the caller did @system operations and
> > passed a bad
> > pointer to the @safe function. But if all of the functions in
> > the call stack
> > are @safe, and you call an @safe function, then you can't get
> > any memory
> > corruption unless it (or a function that it calls) calls an
> > @trusted function
> > which was incorrectly verified by the programmer who marked it
> > as @trusted.
> >
> > - Jonathan M Davis
>
> Updated example from above to show how @safe can introduce UB.
>
> import std.stdio;
>
> class A
> {
> int[] data;
> ~this()
> {
> writeln(data);
> }
> }
>
> void foo(int[] a) @safe
> {
> A x = new A;
> x.data = a;
> }
>
> void main() @safe
> {
> int[4] y;
> foo(y);
> }
That's a known bug in @safe. Slicing a static array should be considered
@system just like taking the address of a local variable is considered
@system:
http://d.puremagic.com/issues/show_bug.cgi?id=8838
The guarantees of @safe hold only so long as there are no holes in it, but any
and all holes we find get fixed. Making ref be truly @safe has been a large
part
of the recent ref discussions, as you can currently get away with doing
something like
ref int id(ref int i) { return i; }
ref int foo()
{
int j;
return id(j);
}
What it looks like we're going to do in this case is detect when this
situation might happen and insert a runtime check which throws an Error if a
reference to a local variable tries to escape, but regardless of the solution,
it's an example of something that is currently considered @safe by the
compiler when it really isn't. All such holes need to be plugged, or @safe
isn't doing its job.
So, if you find any more holes in @safe, please report them in bugzilla:
http://d.puremagic.com/issues
- Jonathan M Davis
