D issues are now tracked on GitHub. This Bugzilla instance remains as a read-only archive.
Issue 22095 - Closure not created or corrupted when accessing pointer in inline function
Summary: Closure not created or corrupted when accessing pointer in inline function
Status: RESOLVED DUPLICATE of issue 8538
Alias: None
Product: D
Classification: Unclassified
Component: dmd (show other issues)
Version: D2
Hardware: x86_64 Linux
: P1 critical
Assignee: No Owner
URL:
Keywords: safe, wrong-code
Depends on:
Blocks:
 
Reported: 2021-07-01 06:17 UTC by Vladimir Panteleev
Modified: 2022-08-12 04:55 UTC (History)
2 users (show)

See Also:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this issue.
Description Vladimir Panteleev 2021-07-01 06:17:13 UTC 
///////////////// test.d /////////////////
struct S
{
    int[5] i; // must be 5 or greater
}

void main()
{
    void delegate() dg;

    (){
        S s = {[1,2,3,4,5]};
        auto pS = &s;
        dg = {
            assert(*pS == S([1,2,3,4,5]));
        };
    }();

    dg();
}
//////////////////////////////////////////

The assection
Comment 1 Vladimir Panteleev 2021-07-01 06:25:30 UTC 
(In reply to Vladimir Panteleev from comment #0)
> The assection

The assertion fails, presumably because the memory referenced by the pointer is no longer valid.
Comment 2 kinke 2021-07-01 18:00:24 UTC 
> presumably because the memory referenced by the pointer is no longer valid.

Exactly, but that's to be expected, as it's not captured. The problem is rather that this isn't caught when making everything @safe with -dip1000 - the compiler should complain that the address of local `s` is assigned to a heap closure `pS` with longer lifetime.
Comment 3 Vladimir Panteleev 2021-07-01 21:53:01 UTC 
(In reply to kinke from comment #2)
> Exactly, but that's to be expected, as it's not captured. The problem is
> rather that this isn't caught when making everything @safe with -dip1000 -
> the compiler should complain that the address of local `s` is assigned to a
> heap closure `pS` with longer lifetime.

Not sure what you mean by this. s and pS should both be in the closure. As far as I can see, the code is valid even with @safe/-dip1000, and no warning should be emitted.
Comment 4 Vladimir Panteleev 2021-07-01 22:07:34 UTC 
Oh, does the compiler only put referenced variables in the closure? I thought it was the entire frame. Now this makes sense.
Comment 5 Walter Bright 2022-07-28 06:13:37 UTC 
This looks like the same problem as https://issues.dlang.org/show_bug.cgi?id=8538
Comment 6 Walter Bright 2022-08-12 04:55:53 UTC 

*** This issue has been marked as a duplicate of issue 8538 ***