Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[class.dtor]/12.3 causes linking to depend on run-time behavior #2541

Open
h0nzZik opened this issue Nov 28, 2018 · 3 comments
Open

[class.dtor]/12.3 causes linking to depend on run-time behavior #2541

h0nzZik opened this issue Nov 28, 2018 · 3 comments
Labels
cwg Issue must be reviewed by CWG.

Comments

@h0nzZik
Copy link

h0nzZik commented Nov 28, 2018

Example

Let us have a program Q:

struct S {
  ~S();
};
volatile int x=0;
int main() {
  S s;
  while(true)
    x = 1;
}

Is the destructor S::~S is odr-used in Q? I guess we want it to be the case. Can we prove that from the wording? Let us try this line of reasoning:

Proof fails

[basic.def.odr]/8

A destructor for a class is odr-used if it is potentially invoked

[class.dtor]/12

A destructor is potentially invoked if it is invoked or as specified in 7.6.2.4, 9.3.1, 10.9.2,
and 13.1.

[class.dtor]/12 (again)

A destructor is invoked implicitly [...] for a constructed object with automatic storage duration (6.6.4.3) > when the block in which an object is created exits.

From the source code of Q:

The block in which a variable of a class type S is declared, exits.

But the block does not exit. So the argument fails.

Discussion

Sure, the block ends - at some position in the source code. But it does not exit. The term "Exit of a block" refers to an execution event, not to a place in source code. Compare with [stmt.jump]/8:

On exit from a scope (however accomplished), objects with automatic storage duration (6.6.4.3)
that have been constructed in that scope are destroyed in the reverse order of their construction.

Another argument is that the standard does not say

A destructor is invoked implicitly [...] where the block in which an object is created exits.

or

A destructor is invoked implicitly [...] if the block in which an object is created exits.

but

A destructor is invoked implicitly [...] when the block in which an object is created exits.

In other words, it says:

At the time when the program is running and the block exits, the destructor is implicitly invoked.

It does not say:

At the place of the source code where the block ends, the destructor is implicitly invoked.

But how can a link-time property (odr-use) depend on an execution event?

Other

Based on this discussion. I came across this problem when working on a formal semantics of C++.

@jensmaurer
Copy link
Member

First, let me state that "odr-use" is intended as a compile-time / link-time property, not as a runtime property. The phrasing "potentially invoked" was added recently to capture odr-uses of destructors that are not always executed. I feel this is a core issue, not an editorial concern.

@h0nzZik
Copy link
Author

h0nzZik commented Nov 29, 2018

Thanks, @jensmaurer. In that case, should I close this (editorial,github) issue and follow this guideline for submitting a core issue?

Also, the same problem may be with [class.dtor]/12.4

A destructor is invoked implicitly [...] for a constructed temporary object when its lifetime ends.

@jensmaurer
Copy link
Member

I've forwarded this to the internal committee mailing list to get it registered as a core issue. There, someone else pointed out that we have a definition/use problem with "invoke": In some places, it is intended as a static property of a program; in other places, it is intended as a dynamic execution-flow property. There would actually be value in clearly differentiating these ideas (e.g. by using different words). This would also fix the issues mentioned here.
Let's keep this open for the time being, but don't expect much progress here in the near future.

@jensmaurer jensmaurer added the cwg Issue must be reviewed by CWG. label Nov 29, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
cwg Issue must be reviewed by CWG.
Projects
None yet
Development

No branches or pull requests

2 participants