target

integration into IS ISO/IEC 9899:202y

document history

1 Motivation

To qualify if an array is a VLA or not, the status of the so-called “size” expression is important. If it is an integer constant expression, the array is not a VLA and all its properties are determined at translation time. Otherwise, it is a VLA and the type expression is “evaluated” whenever size information is needed. In particular, type expressions of VM types where the “size” expression has side effects may (or may not) be evaluated each time it is met during execution, and thus the side effects may or may not take place.

We think that this “feature” is is actually a bug of the specification and that real world examples where side effects appear in “size” expressions are rare and most often erroneous. They may appear when the “size” expression is a macro invocation or a function call, and when the extent to which side effects appear are not properly mastered.

Unfortunately, the following features are often confused

• the syntactic position of an expression
• the point in time during execution when an expression is met,
• the point in time when an expression is evaluated, in particular if an expression is evaluated at
  • translation time (e.g integer constant expressions),
  • at link time (e.g address constants), or
  • during the execution of the program when it is met,
• and whether or not an evaluation has a side effect.

Note that to determine if a type is a VM type or not, in general the distinction between link time and execution is not relevant, so in the following we will not distinguish these two cases. We are left with three possibilities for “size” expressions:

1. it is an integer constant expression
2. otherwise, it is an expression of integer type but never has side effects
3. otherwise, it is an expression of integer type that in some executions may have a side effect.

The goal of this papers is constrain the definitions of array declarator such that the third case never happens, and so to guarantee that the only form of runtime evaluation that happens when meeting a VLA type expression is an implicit lvalue conversion of the hidden information about the number of elements.

The proposed change is normative.

The idea is to restrict possible “size” expressions already syntactically as far as that is possible. The technique is similar to the one already used for “constant expression”. Namely the term is derived from “conditional expression” and then constrained further as necessary:

• The term “conditional expression” already excludes all forms of assignments so this form of side effect is already excluded if this is itself an assignment.
• The only arithmetic expression that may have side effects are assignment, increment and decrement operations, so we disallow these.
• Another possible side effect is a read operation on a volatile lvalue.
• Then, side effects could still occur during function calls, so we restrict the possible function calls to the properties that are collected for the [[reproducible]] attribute, namely of being effectless and idempotent..

Only the last point cannot always be detected at translation time; the called function may be the result of the evaluation of a modifiable function pointer, and may thus change each time the function call expression is met. Thus this last requirement cannot be expressed as a constraint and is a condition that leads to undefined behavior. Also, for this last point we chose the minimum combination of features that is necessary for the desired properties; namely effectless to ensure that no store operations are issued and idempotent to ensure that no other observable changes to the state occur.

Whether or not we then keep up the term VLA (to which people are accustomed) and whether or not we use size/length/extend/count… is of secondary interest and could be done in a second phase.

2 Suggested additions and changes to the wording.

New text is underlined green, removed text is stroke-out red.

2.1 Add the term reproducible expression

Add a new clause 6.5’ before 6.6 (Constant expressions)

6.5’ Reproducible expressions

Syntax

reproducible-expression: conditional-expression

Description

A reproducible expression can be evaluated in any place without changing the observable program state.

Constraints

A reproducible expression shall not be or contain

• an assignment operator,
• an increment operator,
• a decrement operator,
• a conversion of an lvalue with volatile type.

Semantics

If a reproducible expression is evaluated and contains a function call expression, the called function shall be effectless and idempotent and all pointed to base types of parameters shall be const-qualified.^FNT)

^FNT) That is, the function pointer expression of the call can be converted in place to a function pointer type with an [[reproducible]] attribute and where all pointer parameters, if any, are restrict-qualified and have a const-qualified base type without changing the semantics of the program.

2.2 Constrain the syntax of array declarations

Replace the grammar term assignment-expression used in

• array-declarator (6.7.7.1, Declarators, General)
• 6,7.7.3, Array declarators, p3
• array-abstract-declarator (6.7.8 Type names)

by reproducible-expression.

3 Interaction with other proposals

If n3393 is accepted concurrently, the additions of the word “assignment” there should instead read “reducible”.