Union padding values in C/GCC 4.6.3

Question 1

Your unions u1 and u2 are automatic and stored on stack. Automatic variables get initialized to garbage by default in C. What you see in dumps is the old values on the stack, which were there before calling main(). They are semi-aleatory, depending on what the C runtime library does before calling your main().

The structures x1-x6 in your code are different, they are static and static variables get initialized to zeroes by the C-standard.

Variables defined inside functions are automatic (unless declared static), but variables outside of functions can only be static. To make the answer fuller, there is another storage class, the heap or dynamic memory, accessed with malloc()/free(). Only the static variables have fixed location in memory during the entire program run time, the other locations loose meaning when the respective function returns, or when the heap block is freed. These are both popular sources of errors in C programs.

Question 2

From the C99 standard, 6.2.6.1p7:

When a value is stored in an object of structure or union type, including in a member object, the bytes of the object representation that correspond to any padding bytes take unspecified values.

Question 3

Your unions are on the stack and not global there is no expectation whatsoever as to what they are initialized to before you start using them. Officially you should never read a union or any variable for that matter that you have not written first.

There really are no valid expectations for how much or the state of the padding if any in a structure or naturally a union that uses structures or a union without structures.

If you had made them global then there would be a somewhat valid expectation for them to start off zeroed, but I personally dont subscribe to that expectation and try to always explicitly set a variable (write) before I read it the first time. Once you start messing with items in the union though then all bets are off as to what affects what.

EDIT

Your unions are non-static local variables so they are on the stack and as such have no expectation for initialization by the C compiler before you start accessing them.

The only valid use of items in a union are to read back the most recently accessed paths you wrote to.

so

union U1 u1;
union U2 u2;

/* (...) */

     u1.i = 0x01020304;      // initializes int

so the only valid use case here is to read back u1.i. you should not have any expectations at this point for any of the u1.c[] values. and you should not have any expectations for any of the other padding in the whole of the memory the union uses. The only thing the C compiler has to insure is that if you set u1.i then when you read it back assuming you have not modified the union using u1.c in this case, you will get back what you wrote.

    for (i=0;i<5;i++)        // initializes char
        u1.c[i] = 0xcc;

same answer, the only valid read of the union at this point is the u1.c[] items, reading u1.i has no valid expecatations. likewise dumping the whole union can have padding such that the string makes sense and the read back of like items (u1.c[n]) is what you wrote.

u2.s = 0x0102;           // initializes short

then accessing u2.c[] makes no sense and there are no valid expectations. dumping the union the only expectation is that two consecutive bytes somewhere in the union are 0x01 and 0x02 in the endian order for that architecture.

for (i=0;i<5;i++)        // initializes char
u2.c[i] = 0xcc;

then accessing u2.s makes no sense and there are no valid expecations. dumping the union the only expectation is that somewhere in the union are the bytes 0xcc, 0xcd, 0xce, 0xcf, 0xd0 in the proper order, where in the union and the values of the padding you should have no expectations about.

Now saying that I have often been able to use unions improperly to poke at floating point numbers for example and it tends to (so far always) work, but I am aware that that code may just stop working some day when it is compiled by a different version of the same compiler, a different compiler or the same compiler with different compile options. I expect it may fail some day.