Is this type punning well defined?

Is this type punning well defined?

struct result{
    int a,b,c,d;
}

union convert {
   int arr[4];
   struct result res;
}

int arr1[4] = {1,2,3,5};
union convert *pointer = (union convert *) arr1; 

(union convert *) arr1 risks alignment failure.

A pointer to an object type may be converted to a pointer to a different object type. If the resulting pointer is not correctly aligned for the referenced type, the behavior is undefined. C11dr §6.3.2.3 8

There is no requirement that union convert and int share the same alignment. union convert requirements may exceed int for example.

Consider this possibility: arr1[] lives on int street where all addresses are multiple of 4. union and struct friends lives on "multiple of 8" street. arr1[] might have address 0x1004 (not a multiple of 8).

In 2019, alignment failures are more commonly seen with char (needing 1) and other types needing 2 or more. In OP's select case, I doubt a real platform will have alignment issues, yet incorrect alignment remains possible.

This type punning is not well defined.


Additional concerns

Other answers and comments discuss padding issues, which further identifies trouble.

@Eric Postpischil comment about improper access with pointer->res.a adds more reasons to consider this UB.


C imposes no rule about how much padding is left between 2 consecutive members of a structure.

This is why the implementations define many #pragma directives -- specially to change this behaviour.

So, as the answer of Bathsheba says, ...->b is undefined.

I answered the very same question some time ago, here.


pointer->res.a is fine but the behaviour of pointer->res.b is undefined.

There could be an arbitrary amount of padding between the a and b members.

Some compilers allow you to specify that there is no padding between members but of course then you are giving up portability.