[hnfairy]

Despite the argument at the end, this is undefined behavior in the latest C specification. The code dereferences a pointer one past the last element.

C11 6.5.6/8:

If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated

[feelix]

"it shall not be used as the operand of a unary * operator that is evaluated"

he doesn't use the * operator on it, he just calculates its position. If he were to access it (ie, use it with *) then that would be breaking the rule

[dom0]

The snipper only calculates the pointer, and does not dereference it. Should be fine.

[Buge]

It's a complicated situation. There's a pointer to an array, and that pointer is dereferenced, resulting in an array (that then decays to a pointer). But that second array/pointer is not dereferenced. I'm not sure if it's legal.

[cbsmith]

Where is it dereferencing the array?

    *(&arr + 1) - arr

That translates to taking the address one point past the array and subtracting the address of the array from it. It doesn't actually dereference the location past the end of the array.

While:

    (&arr)[1] - arr

might appear to be doing something different, it actually isn't.

[Buge]

&arr is a pointer to an array (it points to the existing array).

&arr + 1 is a pointer to an array that begins just after the existing array.

* is the dereference operator, so it seems to me that *(&arr + 1) dereferences the pointer to the array, resulting in an array (or a reference to an array), which then decays to a pointer.

[feelix]

>so it seems to me that (&arr + 1) dereferences the pointer to the array

It doesn't. Because an array is already a pointer, in (&arr + 1) &arr is a pointer to a pointer (ie, a handle) so *(&arr) is dereferencing the handle to the pointer. So it's still one pointer level deep - it doesn't dereference it completely.

[int_19h]

It doesn't matter what it is a pointer to, type-wise. It is still a pointer one-past-the-end, and it is being dereferenced.

Also, &arr is not a pointer to a pointer. It's a pointer to an array. Specifically, its type is int(* )[5] in this example, and so when you dereference it, the result is of type int[5]. So if you do e.g. sizeof(* &arr + 1), you'll get 5 * sizeof(int).

[cbsmith]

Ah, but since it is dereferencing an array... you haven't actually dereferenced to the memory location yet. If you had, you wouldn't be possible to subtract a pointer from it.

[amelius]

I think the authors of the spec really meant something else: reading/writing a memory location past the end of the array is illegal. But here "*" is used only in an address computation, not to actually access memory.

Shows how difficult it is to get a spec right.

So, IMO, you are right, the code in the article is illegal (strictly speaking).

But I think it is likely that most compilers would still allow it, because that clause in the spec essentially exempts the compiler from adding an explicit bounds check.

[bonzini]

I don't think this is illegal. What is the clause in the spec that allows &arr[1]? I would try and see if it also applies to (&arr)[1].

[clarry]

The clause that allows pointing one past the last element of an array is the same clause that explicitly forbids the latter (keeping in mind that E1[E2] is identical to ( * ((E1)+(E2)))).

N1256 6.5.6p8

When an expression that has integer type is added to or subtracted from a pointer, the result has the type of the pointer operand. If the pointer operand points to an element of an array object, and the array is large enough, the result points to an element offset from the original element such that the difference of the subscripts of the resulting and original array elements equals the integer expression. In other words, if the expression P points to the i-th element of an array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N has the value n) point to, respectively, the i+n-th and i-n-th elements of the array object, provided they exist. Moreover, if the expression P points to the last element of an array object, the expression (P)+1 points one past the last element of the array object, and if the expression Q points one past the last element of an array object, the expression (Q)-1 points to the last element of the array object. If both the pointer operand and the result point to elements of the same array object, or one past the last element of the array object, the evaluation shall not produce an overflow; otherwise, the behavior is undefined. If the result points one past the last element of the array object, it shall not be used as the operand of a unary * operator that is evaluated.

The last sentence right there forbids what we're doing here.

6.5.3.2p3 allows dereference with address-of (&a[1]):

The unary & operator yields the address of its operand. If the operand has type ''type'', the result has type ''pointer to type''. If the operand is the result of a unary * operator, neither that operator nor the & operator is evaluated and the result is as if both were omitted, except that the constraints on the operators still apply and the result is not an lvalue. Similarly, if the operand is the result of a [] operator, neither the & operator nor the unary * that is implied by the [] is evaluated and the result is as if the & operator were removed and the [] operator were changed to a + operator. Otherwise, the result is a pointer to the object or function designated by its operand.

The exception in this clause clearly does not apply to (&arr)[1] because the operand of & is not a result of the * (or []) operator.