https://issues.dlang.org/show_bug.cgi?id=20881

ag0aep6g <ag0aep6g@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid, safe
                 CC|                            |ag0aep6g@gmail.com

--

https://issues.dlang.org/show_bug.cgi?id=20881

--- Comment #1 from ag0aep6g <ag0aep6g@gmail.com> ---
Can we actually return a problematic pointer this way? As it is, the test case only returns `null`s.

It seems that without attribute inference, DMD assumes `get` might return a problematic pointer. But with attribute inference, DMD looks at the actual expression that is being returned.

--

https://issues.dlang.org/show_bug.cgi?id=20881

--- Comment #2 from Stanislav Blinov <stanislav.blinov@gmail.com> ---
Of course we can. What ptr points to and how its value came to be is irrelevant for this test case, thus omitted.

--

https://issues.dlang.org/show_bug.cgi?id=20881

--- Comment #3 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Stanislav Blinov from comment #2)
> Of course we can. What ptr points to and how its value came to be is irrelevant for this test case, thus omitted.

Please show an example. When I tried returning a problematic pointer, DMD showed the same error as in the `Correct` case.

--

https://issues.dlang.org/show_bug.cgi?id=20881

--- Comment #4 from Stanislav Blinov <stanislav.blinov@gmail.com> ---
(In reply to ag0aep6g from comment #3)

> Please show an example. When I tried returning a problematic pointer, DMD showed the same error as in the `Correct` case.

? malloc it in a constructor, free it in a destructor, disable copy and assignment

--

https://issues.dlang.org/show_bug.cgi?id=20881

--- Comment #5 from ag0aep6g <ag0aep6g@gmail.com> ---
(In reply to Stanislav Blinov from comment #4)
> ? malloc it in a constructor, free it in a destructor, disable copy and assignment

Makes sense. When I think about DIP 1000, I tend to think of pointers to the stack. But yeah, it's also supposed to enable malloc/free, isn't it.

For future readers, a full example:

----
import core.stdc.stdlib: free, malloc;
struct Faulty
{
    private int* ptr;
    this(int v) @trusted
    {
        ptr = cast(int*) malloc(int.sizeof);
        *ptr = v;
    }
    ~this() @trusted { if (ptr !is null) free(ptr); }
    @disable this(this);
    @disable void opAssign(Faulty);
    int* get1() @safe return { return ptr; }
    int* get2()() @safe return { return ptr; }
}
void main() @safe
{
    int* outlive;
    {
        auto f1 = Faulty(42);
        outlive = f1.get1(); /* error */
        outlive = f1.get2(); /* should be error */
    }
    /* `outlive` is invalid from here on */
}
----

--

https://issues.dlang.org/show_bug.cgi?id=20881

--- Comment #6 from ag0aep6g <ag0aep6g@gmail.com> ---
The method is being inferred as `return scope`. Oddly enough, that doesn't show up when printing with `pragma(msg, ...)`.

With this information, we can construct a test case that shows memory corruption even without malloc/free and @trusted:

----
struct Faulty
{
    private int x;
    private int* unused;
    int* get1() @safe return scope { return &x; }
}
int* f(int x) @safe
{
    auto f = Faulty(x);
    return f.get1(); /* Returns a pointer to the stack. */
}
void main() @safe
{
    int* p1 = f(42);
    int* p2 = f(13);
    import std.stdio;
    writeln(*p1); /* Prints "13". Whoopsie. */
}
----

--

https://issues.dlang.org/show_bug.cgi?id=20881

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thomas.bockman@gmail.com

--- Comment #7 from Dennis <dkorpel@live.nl> ---
*** Issue 22528 has been marked as a duplicate of this issue. ***

--

https://issues.dlang.org/show_bug.cgi?id=20881

Dennis <dkorpel@live.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dkorpel@live.nl
            Summary|[DIP1000] Templates seem to |[DIP1000] scope inference
                   |ignore 'return'             |turns return-ref into
                   |(workaround)                |return-scope

--- Comment #8 from Dennis <dkorpel@live.nl> ---
There's multiple things going on, so I'm going to limit this issue to "scope inference turns return-ref into return-scope", the issue that the compiler confuses `return scope` and `return ref` internally should be covered by issue 22108 and issue 22541.

--

https://issues.dlang.org/show_bug.cgi?id=20881

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com
           See Also|                            |https://issues.dlang.org/sh
                   |                            |ow_bug.cgi?id=22528

--