Orsdxy

I have structure like below.

struct result{

    int a;

    int b;

    int c;

    int d;

}

and union like below.

union convert{

   int arr[4];

   struct result res;

}

and I type pun as below.

  int arr1[4] = {1,2,3,5};

  union convert *pointer = (union convert *) arr1; // Here is my question, is it well defined?



  printf("%d %dn", pointer->res.a, pointer->res.b);

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.

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.

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).

This type punning is not well defined.

Pointer punning is not safe. Use real union punning instead.

Assumptions: the struct is properly packed (no padding between the members)

#include <stdio.h>

#include <string.h>







struct __attribute__((packed)) result{

    int a;

    int b;

    int c;

    int d;

};



union convert{

   int arr[4];

   struct result res;

};



  volatile int arr1[4];



void foo(void)

{



  union convert cnv;



  memcpy(&cnv, (void *)arr1, sizeof(arr1));



  printf("%d %dn", cnv.res.a, cnv.res.b);

}

all modern compilers will optimize out the memcpy call

https://godbolt.org/z/4qtRIF

.LC0:

        .string "%d %dn"

foo:

        mov     rsi, QWORD PTR arr1[rip]

        xor     eax, eax

        mov     rdi, QWORD PTR arr1[rip+8]

        mov     edi, OFFSET FLAT:.LC0

        mov     rdx, rsi

        sar     rdx, 32

        jmp     printf

After the C++ Standard wording, the C Standard wording looks a bit wobbly to me. But I think that the description of the operator -> semantics (http://port70.net/~nsz/c/c11/n1570.html#6.5.2.3p4) (emphasis is mine):

A postfix expression followed by the -> operator and an identifier designates a member of a structure or union object. The value is that of the named member of the object to which the first expression points, and is an lvalue.

means that a postfix expression followed by the -> operator shall refer to an existing object of the type it points to (there is no such "shall" in the wording, though). And in your case, there is no object of type union convert.