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

--- Comment #10 from moonlightsentinel@disroot.org ---
(In reply to Dennis from comment #8)
> This is important for making Phobos's tempCString @safe:
> 
> ```
>     // $(RED WARNING): $(RED Incorrect usage)
>     auto pInvalid1 = str.tempCString().ptr;
>     const char* pInvalid2 = str.tempCString();
>     // Both pointers refer to invalid memory here as
>     // returned values aren't assigned to a variable and
>     // both primary expressions are ended.
> ```


That usage won't be affected by fixing this bug? The issue in the example arises because the pointer is extracted due to implicit conversion while the temporary buffer is destructed at the end of the statement.

That could only work if the temporary was kept alive over multiple statements (which breaks other language rules w.r.t. temporaries)

--

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

--- Comment #11 from Dennis <dkorpel@live.nl> ---
(In reply to moonlightsentinel from comment #10)
> That usage won't be affected by fixing this bug?

You're right, I was looking into an accepts-invalid dip1000 issue and this looked like a duplicate, but since it's returning by value here it's actually different.

--

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

RazvanN <razvan.nitu1305@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |backend
                 CC|                            |razvan.nitu1305@gmail.com

--- Comment #12 from RazvanN <razvan.nitu1305@gmail.com> ---
Most likely this is a backend issue since I cannot reproduce this with ldc.

--

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

vitamin <submada@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |submada@gmail.com

--- Comment #13 from vitamin <submada@gmail.com> ---
This bug still exists and it depends on existence of dtor in struct:

```d


struct Foo{
    int i;

    ~this()@safe
    {
        i = 0;
    }
}

struct Bar{
    int i;

    //no dtor!

}

void main()@safe{
    scope int* foo = &Foo(1).i; //Compile OK but shouldn't.
    scope int* bar = &Bar(1).i; //Error: `Bar(2).i` is not an lvalue and cannot
be modified
}

```

--

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

Walter Bright <bugzilla@digitalmars.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugzilla@digitalmars.com

--- Comment #14 from Walter Bright <bugzilla@digitalmars.com> ---
(In reply to vitamin from comment #13)
> This bug still exists and it depends on existence of dtor in struct:

It now produces the errors:

test.d(19): Error: address of variable `__slFoo3` assigned to `foo` with longer
lifetime
test.d(20): Error: `Bar(1).i` is not an lvalue and cannot be modified

But the other manifestations of the problem still compile without error.

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

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

--- Comment #15 from Dlang Bot <dlang-bot@dlang.rocks> ---
@WalterBright created dlang/dmd pull request #14358 "fix Issue 20809 - return statement might access memory from destructe…" fixing this issue:

- fix Issue 20809 - return statement might access memory from destructed temporary

https://github.com/dlang/dmd/pull/14358

--

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

Dlang Bot <dlang-bot@dlang.rocks> changed:

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

--- Comment #16 from Dlang Bot <dlang-bot@dlang.rocks> ---
dlang/dmd pull request #14358 "fix Issue 20809 - return statement might access memory from destructe…" was merged into master:

- 35af96b308228cf6df9dcb409b4fee0ee2ddc3e6 by Walter Bright:
  fix Issue 20809 - return statement might access memory from destructed
temporary

https://github.com/dlang/dmd/pull/14358

--