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

[stmt.dcl]/3 is not precise #4741

Closed
xmh0511 opened this issue Jul 9, 2021 · 4 comments · Fixed by #4763
Closed

[stmt.dcl]/3 is not precise #4741

xmh0511 opened this issue Jul 9, 2021 · 4 comments · Fixed by #4763
Assignees

Comments

@xmh0511
Copy link
Contributor

xmh0511 commented Jul 9, 2021

  1. A variable with automatic storage duration ([basic.stc.auto]) is active everywhere in the scope to which it belongs after its init-declarator.

  2. Upon each transfer of control (including sequential execution of statements) within a function from point P to point Q, all variables that are active at P and not at Q are destroyed in the reverse order of their construction. Then, all variables that are active at Q but not at P are initialized in declaration order;

Presumably, the mentioned variables in bullet 3 should all refer to the variables with automatic storage duration. Although, bullet 2 defines how the variable with automatic storage duration would be active. However, the rule didn't assert whether the variables with other storage durations also have the attribute active somewhere. It is a bit ambiguous.

I think we should either clarify bullet 2 or directly expose the storage duration of the variables in bullet 3 should have, in order to eliminate this ambiguity. For instance

Only if the variable has automatic storage duration ([basic.stc.auto]), it is active everywhere in the scope to which it belongs after its init-declarator.

In short, this issue sounds like P => Q.

@jensmaurer
Copy link
Member

@opensdh
Beyond the possibly-cosmetic addition of "with automatic storage duration" to p3, I'm wondering whether the "active at Q but not at P" should mention the initialization of local statics somehow. (Those are initialized as control passes through their declaration, too.)

@xmh0511
Copy link
Contributor Author

xmh0511 commented Jul 9, 2021

It seems p3 does not intend to cover the block variable with static storage duration since transferring the control from P to Q that is not the valid scope of the variable does not destroy the variable(with static storage duration).

[stmt.dcl#4] is used to phrase the initialization of the block variable with static storage duration while [basic.start.term] covers the destruction of that variable.

Dynamic initialization of a block variable with static storage duration or thread storage duration is performed the first time control passes through its declaration;

In other words, the initialization of the block variable with static storage duration does not occur every time the control passes through its declaration, this is the divergence between the initialization mentioned in p3 and it.

@jensmaurer
Copy link
Member

Agreed. p3 should only cover variables with automatic storage duration. Maybe it helps to eliminate the paragraph break between p2 and p3, so that the definition of "active" is directly before its use.

@opensdh
Copy link
Contributor

opensdh commented Jul 9, 2021

It seems plausible to have /3 destroy only variables with automatic storage duration but initialize all of them, which would replace /4's "first time control passes through" which doesn't really have any definition. However, the rest of that paragraph doesn't seem particularly easy to merge, so maybe it's better to leave it alone and just merge the paragraphs as suggested (since "active" isn't meant to apply to any other kind of variable anyway).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants