Jump to page: 1 2
Thread overview
July 13, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, wrong-code

--
July 13, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

--- Comment #1 from hsteoh@quickfur.ath.cx ---
Better yet, the following variation shows @safe breakage:
----
import std.stdio;
class C {
        int x;
        this(int _x) { x = _x; }
        ref C evil() @safe {
                return this; // <-- should not compile but does
        }
}
void hmm(int x, int y, ref C c) {
        () @safe {
                c = null;       // corrupt memory -- in @safe block
        }();
        writefln("%d %d", x, y); // prints "0 2"
}
void main() {
        auto c = new C(1);
        auto d = new C(2);
        hmm(1, 2, c.evil()); // N.B., we passed 1 and 2 to hmm()
}
----

--
July 13, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |safe

--
July 13, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

--- Comment #2 from hsteoh@quickfur.ath.cx ---
Attempting to do the same with returning a local variable produces a compile error:

test.d(10): Error: escaping reference to local variable c

which is correct. So looks like 'this' was overlooked as a local variable (albeit an implicit one) in the check for escaping references.

--
July 14, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unspecified                 |D2

--
July 14, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

--- Comment #3 from hsteoh@quickfur.ath.cx ---
Note that it's OK to do this with structs because the address of the original struct is returned, not the address of the `this` implicit variable.

--
July 14, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |pull

--- Comment #4 from hsteoh@quickfur.ath.cx ---
https://github.com/D-Programming-Language/dmd/pull/3761

--
July 14, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

--- Comment #5 from hsteoh@quickfur.ath.cx ---
As Kenji points out, this is part of a more general problem where `super` and `this` in class methods are lvalues, so they are liable to illegal rebindings:
----
class Base {
    int x;
}
void rebind(ref Base b) { b = new Base; }
void rebind(ref Derived d) { d = new Derived; }
class Derived : Base {
    int y;
    void evil() {
        rebind(super);
        x = 123; // this modifies a different copy of Base.x than this one!

        rebind(this);
        y = 123; // this modifies a different copy of this.y !
    }
}
----
This problem can be solved if we make `this` and `super` rvalues in class methods. Note that in struct methods, `this` is OK to be an lvalue, because structs are by-value types so no rebinding is involved in the struct analog of the above code; it modifies the struct in-place.

--
August 05, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

--- Comment #6 from github-bugzilla@puremagic.com ---
Commit pushed to master at https://github.com/D-Programming-Language/dmd

https://github.com/D-Programming-Language/dmd/commit/24e8347f1fa4ccbb1cc6a27c40eedef1324e6c13 Merge pull request #3761 from quickfur/issue13116

Issue 13116: should reject returning `this` from a ref class member function

--
August 05, 2014
https://issues.dlang.org/show_bug.cgi?id=13116

hsteoh@quickfur.ath.cx changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--
« First   ‹ Prev
1 2