Doc. no.: N1965
Date: 2015-09-24
Reply to: Clark Nelson clark.nelson@intel.com

Proposed resolution for DR 439

Introduction

DR 439 raises five points.

Point A is believed to be editorial. Proposed fixes are included below under point C, for convenience.

Point B may require non-normative clarification, but the committee wishes to discuss further. This paper contains no new contribution.

Point C is the most significant, probably requiring normative fixes. My proposal is below.

Point D needs further discussion towards a committee response. See below for a suggestion.

Point E probably requires some mostly-editorial change. See below for a suggestion.

Point C: Full declarators

The concept of a full declarator is used for two distinct purposes:

But the description of the latter is not coherent in C11. (To be fair, it may have been less incoherent in C99.)

I originally proposed to talk about “elaboration” of a declarator, as in Ada, and to specify that the execution of a program consists of a (partially ordered) sequence of full expression evaluations and full declarator elaborations.

But it seemed simpler to keep the idea of a sequence of full expression evaluations, and posit an implicit full expression for a full declarator for a variably modified type. That alternative is presented here.

Change 6.2.4p8:

A non-lvalue expression with structure or union type, where the structure or union contains a member with array type (including, recursively, members of all contained structures and unions) refers to an object with automatic storage duration and temporary lifetime.36) Its lifetime begins when the expression is evaluated and its initial value is the value of the expression. Its lifetime ends when the evaluation of the containing full expression or full declarator ends. Any attempt to modify an object with temporary lifetime results in undefined behavior.

Change 6.7.6p3:

A full declarator is a declarator that is not part of another declarator. The end of a full declarator is a sequence point. If, in the nested sequence of declarators in a full declarator, there is a declarator specifying a variable length array type, the type specified by the full declarator is said to be variably modified. Furthermore, any type derived by declarator type derivation from a variably modified type is itself variably modified.

Change 6.8p4:

A full expression is an expression that is not part of another expression, or nor part of a declarator or abstract declarator. Each of the following is a full expression: an initializer that is not part of a compound literal; the expression in an expression statement; the controlling expression of a selection statement (if or switch); the controlling expression of a while or do statement; each of the (optional) expressions of a for statement; the (optional) expression in a return statement. There is also an implicit full expression in which the non-constant size expressions for a variably modified type are evaluated; within that full expression, the evaluations of different size expressions are unsequenced with respect to one another. There is a sequence point between the evaluation of a full expression and the evaluation of the next full expression to be evaluated.

Delete a bullet from Annex C:

Point E: The list of full expressions

This could be added as a new note paragraph in 6.8, or as a new paragraph in (informative) Annex C. Either way, the existing list of full expressions under a bullet in Annex C should be deleted.

Each of the following is a full expression:

While a constant expression satisfies the definition of a full expression, evaluating it does not depend on nor produce any side effects, so the sequencing implications of being a full expression are not relevant to a constant expression.

The text that is not new was taken verbatim from 6.8p4. I have reformatted it as a bullet list, for the convenience of the reader.

Point D: Abstract declarators

These changes would implement what I suggested in my original paper. I drafted them before I went back to the DR list and was reminded that the committee apparently didn't agree with my original suggestion. I present them here as an alternative to throwing away the drafting, and to prompt discussion.

Change 6.7.2.4p3:

The type name in an atomic type specifier shall not refer to an array type, a variably modified type a function type, an atomic type, or a qualified type.

Add a new paragraph following 6.7.5p2:

The type name shall not refer to a variably modified type.