target

integration into IS ISO/IEC 9899:202y

document history

Polls by WG14, Oct 2024, Minneapolis

license

CC BY, see https://creativecommons.org/licenses/by/4.0

1 Discussion

Traditionally, the definition of array subscripting goes through conversion of the array to a pointer. Thus, E[m] is defined as (*((E)+(m))), where E is converted to a pointer to its first element. On first sight it may seem there is no semantic difference between this and saying that “E[m] denotes the m^th element of the array”. But indeed there is; the paragraph on conversion of an array to a pointer says

Except when […], an expression that has type “array of type” is converted to an expression with type “pointer to type” that points to the initial element of the array object and is not an lvalue. If the array object has register storage class, the behavior is undefined.

Therefore, subscripting an array precludes its declaration with register. This seems an artificial restriction, existing only because of the way E[m] is defined. Implementations such as gcc have lifted this restriction since decades.

It was also noted that the expression *(E+m) produces an lvalue in instances where a non-lvalue would be expected for E[m], as in

struct {const int i; int arr[1];} func();
func().i;           // not lvalue
func.arr[0];        // equivalent to the following
*(func().arr+0);    // non-const, immutable lvalue with temporary lifetime

This paper changes this, and so the provision of the standard that introduces temporary object for values with an array member, will only trigger in the rare case that the array member is used in places where a pointer value is expected. With the proposed changes we have

struct {const int i; int arr[1];} func();
func().i;           // not lvalue, no temporary object instantiated
func.arr[0];        // not lvalue, no temporary object instantiated
*(func().arr+0);    // non-const, immutable lvalue with temporary lifetime

A similar restriction is present for the use as integer constant expressions (ICE). Consider

constexpr int x[3]= {0,10,20};
float y[x[1]];

This code is not valid because x[1] is not an integer constant expression. Since the whole object x is a constant expression, it seems each of its members should be usable as ICE. Previous versions of this paper tried to change this, but now we delay this to a follow-up paper.

Other problems arose when studying the extension of the subscripting operation to allow range selections.

1.1 Constraint on the subscript

In an expression E[M], where E is an array, we propose M to be ≥ 0 and for it to be a constraint if M is an integer constant expression. This is not imposed if E has pointer type, neither as constraint nor as UB. In particular, for a pointer p the common idiom p[-1] remains valid. If E is an array this was already invalid, since, from the definitions of arrays in C, the element E[-1] does not exist, even if E were to decay to a pointer. Thus:

int A[3][3];
A[1][-1];  // A[1] is an array of three elements; say, B. B[-1] does not exist.
           // In *(B-1), the pointer B (once B decays to a pointer) points to the
           // the first element of an array of 3 elements. B-1 is not a valid pointer.
           // Hence, *(A[1]-1), hence A[1][-1], has UB as per the current standard.

An implementation may very well define this behavior and allow it. More likely, an implementation may just compute the adress A[1]-1 and have this code work without defining the behavior (it just works). Programmers relying on that can rewrite A[1][-1] (which henceforth will raise a diagnostic) to *(A[1]-1) in order to avoid the diagnostic.

Nevertheless it is unclear to us if that UB is not used by optimizers to make assumptions about subscripts, so using this UB on arrays is inherently dangerous. Therefore we propose to promote this from UB to a constraint in situations that are easily detectable at translation time, namely when the subscript is an ICE.

1.1.1 Drawback

The following code is valid today and would require a diagnostic if the constraint is introduced also for an out-of-bounds access beyond the array length:

#define SAFE_ACCESS(a, x) (((x) < ARRAY_SIZE(a)) ? a[x] : 0)
int a[10];
int b = SAFE_ACCESS(a, 10);

This macro is superseded by the constraint, but is still useful for VLA. A user of this macro would have to replace all uses for fixed length arrays by a direct access or change the macro so that the subscript is not an ICE even if x is.

Here the out-of-bound index is valid because the expression is not evaluated. However, writing “if the expression is evaluated” in the constraint is not adequate because being evaluated is a runtime property. There are contexts where the expression is known not to be evaluated already at translation time. It is for these contexts than an execption can be made in the constraint. However, this concept is not developed in the standard, and its introduction falls outside the scope of this proposal.

2 Wording

New text is underlined green, removed text is stroke-out red. Possible reorganization of the paragraphs is left to the discretion of the editors.

2.1 Array-to-pointer decay

6.3.2.1 Lvalues, arrays, and function designators

3 Except when it is the operand of the sizeof operator, or typeof operators, or the unary & operator, or one of the two expressions of an array subscripting operator, or is a string literal used to initialize an array, an expression that has type “array of type” is converted to an expression with type “pointer to type” that points to the initial element of the array object and is not an lvalue. If the array object has register storage class, the behavior is implementation-defined.

2.2 Postfix operators

6.5.3 Postfix operators

6.5.3.2 Array subscripting

Description

1 A postfix expression followed by an expression in square brackets [ ] is a subscripted designation of an element of an array. The use of this operator with the postfix expression of integer type is an obsolescent feature.

Constraints

2 One of the expressions shall have type “pointer to complete object type” or “array of type”, the other expression, called the subscript, shall have integer type, and the result has type “type”. If one of the two expressions has array type and the subscript is an integer constant expression, the value of the latter shall not be negative.

Semantics

3 A postfix expression followed by an expression in square brackets [ ] is a subscripted designation of an element of an array object. The definition of the subscript operator [] is that E1[E2] is identical to (*((E1)+(E2))). Because of the conversion rules that apply to the binary + operator, if E1 is an array object (equivalently, a pointer to the initial element of an array object) and E2 is an integer, E1[E2] designates the E2-th element of E1 (counting from zero). If either expression has pointer type the expression E1[E2] is equivalent to *((E1)+(E2)) and is an lvalue. Otherwise, let E be the expression of array type and let m be the value of the subscript; the array subscript expression designates the m-th element of the array designated by E, counting from zero, it is an lvalue if E is an lvalue, and m shall not be negative and shall be less than the length of the array or equal to it; it can only equal the length of the array if the [] operator is followed by zero or more [] operators with subscripts equal to zero and the resulting postfix expression is the operand of the unary & operator or is converted to an expression with pointer type as described in 6.3.2.1.

4 Successive subscript operators designate an element of a multidimensional array object. If E is an n-dimensional array (n ≥ 2) with dimensions i × j × ⋯ × k, then E[N] (used as other than an lvalue) is converted to a pointer to denotes an (n − 1)-dimensional array with dimensions j × ⋯ × k. If the unary * operator is applied to this pointer explicitly, or implicitly as a result of subscripting, the result is the referenced (n − 1)-dimensional array, which itself is converted into a pointer if used as other than an lvalue. It follows from this that arrays are stored in row-major order (last subscript varies fastest).

5 EXAMPLE The following snippet has an array object defined by the declaration:

int x[3][5];

Here x is a 3 × 5 array of objects of type int; more precisely, x is an array of three element objects, each of which is an array of five objects of type int. In the expression x[i], which is equivalent to (*((x)+(i))), x is first converted to a pointer to the initial array of five objects of type int. Then i is adjusted according to the type of x, which conceptually entails multiplying i by the size of the object to which the pointer points, namely an array of five int objects. The results are added and indirection is applied to yield an array of five objects of type int. When used in the expression x[i][j], that array is in turn converted to a pointer to the first of the objects of type int, so x[i][j] yields an int. The expression x[1] designates the second element of array x, which is itself an array of five objects of type int. Then x[1][2] designates the third element thereof, which is an int. It is the 7-th stored element of the two-dimensional array x (counting from 0).

6.5.4 Unary operators

6.5.4.3 Address and indirection operators

neither the & operator nor the unary *nor the access to the value that is implied by the [] is evaluated

2.3 Storage class register

6.7.2 Storage-class specifiers

Remove the last sentence in the following footnote

¹²⁷⁾ The implementation can treat any register declaration simply as an auto declaration. However, whether or not addressable storage is used, the address of any part of an object declared with storage-class specifier register cannot be computed, either explicitly (by use of the unary & operator as discussed in 6.5.4.3) or implicitly (by converting an array name to a pointer as discussed in 6.3.3.1). Thus, the only operator that can be applied to an array declared with storage-class specifier register is sizeof and the typeof operators.

2.4 Future language directions

6.11 Future language directions

6.11.4a Postfix operators

The use of the array subscripting operator with a postfix expression of integer type followed by an expression of pointer or array type enclosed in square brackets is an obsolescent feature.

3 Acknowledgment

We’d like to thank Martin Uecker and Joseph Myers for their suggestions.