Exercises — Unions — overlapping memory

Every member begins at the same address, offset 0. They physically overlap — there is no separate space per member (that would be a struct).

Sizes are char=1, short=2, int=4. WHY largest? The room must fit whichever member is stored, so it must fit the worst case — the int. Largest = 4, and 4 is already a multiple of int's alignment (4). $\text{sizeof}=\max (1,2,4)=\boxed{4}$

False. Only the member you last wrote holds meaningful data. Reading any other member reads the same bytes reinterpreted — usually garbage. Reading a different member deliberately is type punning, not "reading them all".

Member sizes: char c[10] = 10, int = 4, double = 8. Largest raw size = 10 (the array). WHY alignment matters here: the strictest member is double, alignment 8. The size must be rounded up to a multiple of 8 so that an array of these unions keeps every double 8-aligned. ${\text{align}}_8(10)=\lceil \frac{10}{8}\rceil \times 8=2\times 8=\boxed{16}$ So even though the biggest member is 10 bytes, the union is 16 bytes.

$65=0x00000041$. Little-endian stores the lowest-value byte first: $u.b[0]=0x41,u.b[1]=0x00,u.b[2]=0x00,u.b[3]=0x00$ ASCII 0x41 is 'A', so u.b[0] prints A.

Big-endian stores the highest-value byte first: $u.b[0]=0x00,u.b[1]=0x00,u.b[2]=0x00,u.b[3]=0x41$ So u.b[0] is 0x00 (the NUL character), not 'A'. This is exactly why the character trick from L2.2 is endianness-dependent.

WHY not just "2"? Reading d.i after writing d.f does no arithmetic conversion — it reads the raw float bit pattern as an integer. The IEEE-754 bits for $2.0$: sign $=0$, exponent field $=128$ (biased: $1+127$), mantissa $=0$. Assembling: $\underset{\text{sign}}{\underbrace{0}}\underset{\text{exp}=128}{\underbrace{10000000}}\underset{\text{mantissa}}{\underbrace{0\dots 0}}=0x40000000$ As an integer that is $2^{30}=\boxed{1073741824}$. So it prints 1073741824, not 2.

$1078530011=0x40490FDB$. Decode as IEEE-754:

• sign $=0$
• exponent field $=0x80=128\Rightarrow$ actual exponent $128-127=1$
• mantissa bits $=0x490FDB$, giving fraction $\approx 0.5707964$, so significand $=1.5707964$

$\text{value}=1.5707964\times 2^1\approx \boxed{3.14159265}\approx \pi$ This is the well-known "float bits of $\pi$". It demonstrates that a union just relabels bytes — the number's meaning changes entirely with the member you read.

Little-endian assembles the value as (high byte << 8) | low byte, where the low byte is b[0]: $e.s=(b[1]\ll 8)|b[0]=(0x12\ll 8)|0x34=0x1234$ Prints 1234. Notice we wrote the bytes "backwards" (34 then 12) to get the number 0x1234 — that reversal is little-endianness.

union Color {
    unsigned int rgba;              // whole 32-bit value
    struct { unsigned char r, g, b, a; } ch;  // four channels
};

WHY a struct inside the union? The four channels must live simultaneously (they are separate bytes), so they need separate memory — that is a struct. But that whole 4-byte struct overlaps the unsigned int, so both views share the same bytes. On little-endian, ch.r is byte 0 = lowest 8 bits of rgba. So rgba = 0x11223344 gives ch.r = 0x44, ch.g = 0x33, ch.b = 0x22, ch.a = 0x11.

struct Number {
    enum { NUM_INT, NUM_DBL } tag;   // who is live?
    union { long long i; double d; } val;
};
 
void print_number(struct Number n) {
    if (n.tag == NUM_INT) printf("%lld\n", n.val.i);
    else                  printf("%f\n",   n.val.d);
}

WHY the tag? A union has no runtime memory of which member was last written. The enum tag is your bookkeeping so print_number reads only the member that was actually stored; reading the other would reinterpret unrelated bits. See the tagged-union pattern in the parent note.

The union { long long i; double d; } is 8 bytes (both members are 8, alignment 8). The enum is an int = 4 bytes. Layout: tag at offset 0 (4 bytes), then the union needs 8-byte alignment, so 4 bytes of padding are inserted, then the union at offset 8. $4(\text{tag})+4(\text{pad})+8(\text{union})=\boxed{16}$ The whole struct's alignment is 8 (from the union), and 16 is already a multiple of 8, so no trailing padding. See Memory alignment and padding.

One member: size = that member = sizeof(double) = 8. There is no "sum vs largest" ambiguity with a single lodger. Zero members: an empty union is not valid in standard C — a union must have at least one named member. (Some compilers allow it as an extension with size 0 or 1, but you should not rely on it.)

We wrote only 1 byte (u.c), but reading u.i reads 4 bytes. Byte 0 is 'X' = 0x58; the other 3 bytes were never written, so they hold indeterminate ("garbage") values left over in memory. Therefore u.i is some number of the form 0x??????58 (little-endian) where the ? bytes are unknown. The result is unspecified — the only reliably-set byte is the one u.c touched. Never read a wider member than the one you initialized.

Raw sizes: c[3] = 3, short = 2. Largest raw = 3. Strictest alignment = short's = 2. Round 3 up to the next multiple of 2: ${\text{align}}_2(3)=\lceil \frac{3}{2}\rceil \times 2=2\times 2=\boxed{4}$ So the union is 4 bytes, not 3 — padding of 1 byte is added so arrays of union G keep every short on an even address.

Both members start at offset 0 — they overlap. So tag and byte 0 of d are the same byte. Storing d overwrites tag; storing tag corrupts the low byte of d. Size = largest member double = 8, alignment 8, and 8 is already a multiple of 8, so: $\text{sizeof(union H)}=\boxed{8}$ Key contrast with a struct: in a struct H the two would be at different offsets (0 and 8, with padding), totalling 16 bytes; in the union they share offset 0 and take 8. This is the whole memory-saving point of unions.

A union's members all start at offset 0. A union's size equals its largest member, rounded up for alignment. Reading a member you did not write gives you reinterpreted / garbage bits, not a converted value. A tagged union pairs the union with an enum recording the live member.