Is it undefined behavior to `reinterpret_cast` a `

Question

Consider the following scenario:

std::array<int, 8> a;
auto p = reinterpret_cast<int(*)[8]>(a.data());
(*p)[0] = 42;

Is this undefined behavior? I think it is.

• a.data() returns a int*, which is not the same as int(*)[8]

• The type aliasing rules on cppreference seem to suggest that the reinterpret_cast is not valid

• As a programmer, I know that the memory location pointed by a.data() is an array of 8 int objects

Is there any rule I am missing that makes this reinterpret_cast valid?

Answer 1

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".}

Answer 2

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.