CWG 2026-03-25

CWG believes the original issue is NAD, because the return statement that initiates the transfer of control out of a function is "within" that function.

However, CWG discovered an issue that function calls should not be handled by these rules. This is addressed in the resolution above.

Proposed resolution (approved by CWG 2025-03-25):

Change in 8.10 [stmt.dcl] paragraph 2 as follows:

A block variable with automatic storage duration (6.8.6.4 [basic.stc.auto]) is active everywhere in the scope to which it belongs after its init-declarator . Upon each transfer of control (including sequential execution of statements, but excluding function calls) within a function from point P to point Q, all block variables with automatic storage duration that are active at P and not at Q are destroyed in the reverse order of their construction. Then, all block variables with automatic storage duration that are active at Q but not at P are initialized in declaration order; unless all such variables have vacuous initialization (6.8.4 [basic.life]), the transfer of control shall not be a jump. [ Footnote: ...] When a declaration-statement is executed, P and Q are the points immediately before and after it; when a function returns, Q is after its body.

(From submission #656.)

Subclause 8.10 [stmt.dcl] paragraph 2 specifies:

... Upon each transfer of control (including sequential execution of statements) within a function from point P to point Q, all block variables with automatic storage duration that are active at P and not at Q are destroyed in the reverse order of their construction. ...; when a function returns, Q is after its body.

The phrasing "within a function" can be misread as not applying to transfers out of a function (e.g. execution of a return statement).