pointer escaping return scope bug?

Nick Treleaven nick at geany.org
Sun Nov 27 16:55:29 UTC 2022


On Friday, 25 November 2022 at 15:03:57 UTC, ShadoLight wrote:
>> I don't grok how `lf` can survive the local scope. Or am I 
>> missing something?
>
> Perhaps because the local scope is not pushed as a separate 
> (anonymous) function on the stack... if true then, yes, then 
> `lf` will indeed have the same physical lifetime as main (and 
> `p`)...?
>
> On the other hand, if you add a destructor to `LockedFile`, it 
> will be invoked at the end of the local scope, not the end of 
> main.

Yes, the actual code does have a destructor. It's analogous to 
this:

```d
@safe:

struct S
{
     private int* fps;

     auto fp() return scope => fps;

     this(int)
     {
         fps = new int;
     }

     @disable this();
     @disable void opAssign(S);

     ~this() @trusted // how do we make this safe?
     {
         import core.memory;
         GC.free(fps);
     }
}

void main()
{
     int* p;
     {
         auto lf = S(5);
         p = lf.fp;
     }
     assert(p != null); // address escaped
}
```

That compiles with -dip1000. D doesn't seem to have a way to 
prevent the memory outliving the struct.

Just to note there is another problem when the struct is 
destroyed explicitly whilst the `fp` result is still live. But 
that could be solved by making `object.destroy` and 
`std.algorithm.move` be restricted to @system for certain structs 
like this one (either opt-in or some other mechanism). The first 
problem doesn't seem to have a solution.


More information about the Digitalmars-d-learn mailing list