Is it undefined behavior to `reinterpret_cast` a `T*` to `T(*)[N]`?

Question

Consider the following scenario:

std::array a;
auto p = reinterpret_cast(a.data());
(*p)[0] = 42;

Is this

Answer 1

Yes the behaviour is undefined.

int* (the return type of a.data()) is a different type from int(*)[8], so you are breaking strict aliasing rules.

Naturally though (and this is more for the benefit of future readers),

int* p = a.data();

is perfectly valid, as is the ensuing expression p + n where the integral type n is between 0 and 8 inclusive.

Answer 2

An array object and its first element are not pointer-interconvertible^*, so the result of the reinterpret_cast is a pointer of type "pointer to array of 8 int" whose value is "pointer to a[0]"¹.In other words, despite the type, it does not actually point to any array object.

The code then applies the array-to-pointer conversion to the lvalue that resulted from dereferencing such a pointer (as a part of the indexing expression (*p)[0])². That conversion's behavior is only specified when the lvalue actually refers to an array object³. Since the lvalue in this case does not, the behavior is undefined by omission⁴.

---

_{^*If the question is "why is an array object and its first element not pointer-interconvertible?", it has already been asked: Pointer interconvertibility vs having the same address.}

_{¹See [expr.reinterpret.cast]/7, [conv.ptr]/2, [expr.static.cast]/13 and [basic.compound]/4.}

_{²See [basic.lval]/6, [expr.sub] and [expr.add].}

_{³[conv.array]: "The result is a pointer to the first element of the array."}

_{⁴[defns.undefined]: undefined behavior is "behavior for which this document imposes no requirements", including "when this document omits any explicit definition of behavior".}