Exercises — Unions — overlapping memory

Har member same address, offset 0 se shuru hota hai. Woh physically overlap karte hain — har member ke liye alag space nahi hoti (woh toh ek struct hoti).

Sizes hain char=1, short=2, int=4. WHY largest? Room mein jo bhi member store ho usse fit karna zaroori hai, toh worst case — int — fit hona chahiye. Largest = 4, aur 4 pehle se hi int ki alignment (4) ka multiple hai. $\text{sizeof}=\max (1,2,4)=\boxed{4}$

False. Sirf woh member jisko tum last likhte ho meaningful data rakhta hai. Koi doosra member padhna matlab same bytes ko alag tarike se interpret karna — usually garbage. Deliberately ek alag member padhna type punning hai, "sab ko padhna" nahi.

Member sizes: char c[10] = 10, int = 4, double = 8. Sabse bada raw size = 10 (array). WHY alignment yahaan matter karti hai: strictest member double hai, alignment 8. Size ko 8 ke multiple tak upar round karna zaroori hai taaki in unions ke array mein har double 8-aligned rahe. ${\text{align}}_8(10)=\lceil \frac{10}{8}\rceil \times 8=2\times 8=\boxed{16}$ Toh bhale hi sabse bada member 10 bytes ka hai, union 16 bytes ki hai.

$65=0x00000041$. Little-endian lowest-value byte pehle store karta hai: $u.b[0]=0x41,u.b[1]=0x00,u.b[2]=0x00,u.b[3]=0x00$ ASCII 0x41 hai 'A', toh u.b[0] print karta hai A.

Big-endian highest-value byte pehle store karta hai: $u.b[0]=0x00,u.b[1]=0x00,u.b[2]=0x00,u.b[3]=0x41$ Toh u.b[0] hai 0x00 (NUL character), 'A' nahi. Yahi reason hai ki L2.2 wala character trick endianness-dependent hai.

WHY sirf "2" nahi? d.i padhna d.f likhne ke baad koi arithmetic conversion nahi karta — yeh raw float bit pattern ko ek integer ki tarah padhta hai. $2.0$ ke liye IEEE-754 bits: sign $=0$, exponent field $=128$ (biased: $1+127$), mantissa $=0$. Assemble karo: $\underset{\text{sign}}{\underbrace{0}}\underset{\text{exp}=128}{\underbrace{10000000}}\underset{\text{mantissa}}{\underbrace{0\dots 0}}=0x40000000$ Integer ki tarah woh hai $2^{30}=\boxed{1073741824}$. Toh yeh print karta hai 1073741824, 2 nahi.

$1078530011=0x40490FDB$. IEEE-754 ki tarah decode karo:

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

$\text{value}=1.5707964\times 2^1\approx \boxed{3.14159265}\approx \pi$ Yeh well-known "$\pi$ ke float bits" hai. Yeh demonstrate karta hai ki union sirf bytes ko relabel karta hai — number ka meaning member ke saath completely badal jaata hai jo tum padhte ho.

Little-endian value ko (high byte << 8) | low byte ki tarah assemble karta hai, jahan low byte b[0] hai: $e.s=(b[1]\ll 8)|b[0]=(0x12\ll 8)|0x34=0x1234$ 1234 print hoga. Note karo ki humne bytes "ulte" likhe (34 phir 12) taaki number 0x1234 mile — woh reversal hi little-endianness hai.

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

WHY union ke andar struct? Char channels simultaneously rehne chahiye (woh alag bytes hain), toh unhe separate memory chahiye — woh struct hai. Lekin woh poora 4-byte struct unsigned int se overlap karta hai, toh dono views same bytes share karte hain. Little-endian par, ch.r byte 0 hai = rgba ke lowest 8 bits. Toh rgba = 0x11223344 deta hai ch.r = 0x44, ch.g = 0x33, ch.b = 0x22, ch.a = 0x11.

struct Number {
    enum { NUM_INT, NUM_DBL } tag;   // kaun live hai?
    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 tag? Union ke paas koi runtime memory nahi ki kaun sa member last likha gaya tha. enum tag tumhari bookkeeping hai taaki print_number sirf wahi member padhe jo actually store tha; doosra padhna unrelated bits ko reinterpret karta. Parent note mein tagged-union pattern dekho.

Union { long long i; double d; } 8 bytes ki hai (dono members 8 hain, alignment 8). enum ek int = 4 bytes hai. Layout: tag offset 0 par (4 bytes), phir union ko 8-byte alignment chahiye, toh 4 bytes padding insert hoti hai, phir union offset 8 par. $4(\text{tag})+4(\text{pad})+8(\text{union})=\boxed{16}$ Poore struct ki alignment 8 hai (union ki wajah se), aur 16 pehle se 8 ka multiple hai, toh koi trailing padding nahi. Dekho Memory alignment and padding.

Ek member: size = woh member = sizeof(double) = 8. Ek lodger ke saath "sum vs largest" ki koi ambiguity nahi. Zero members: empty union standard C mein valid nahi — union mein kam se kam ek named member hona chahiye. (Kuch compilers ise extension ke taur par allow karte hain size 0 ya 1 ke saath, lekin uss par rely mat karo.)

Humne sirf 1 byte likha (u.c), lekin u.i padhna 4 bytes padhta hai. Byte 0 hai 'X' = 0x58; baaki 3 bytes kabhi nahi likhe gaye, toh woh memory mein indeterminate ("garbage") values rakhte hain. Isliye u.i koi number hai 0x??????58 (little-endian) ki tarah jahan ? bytes unknown hain. Result unspecified hai — sirf wahi byte reliably set hai jo u.c ne touch ki. Kabhi bhi uss member se wider member mat padho jise tumne initialize kiya tha.

Raw sizes: c[3] = 3, short = 2. Sabse bada raw = 3. Strictest alignment = short ki = 2. 3 ko 2 ke agle multiple tak round up karo: ${\text{align}}_2(3)=\lceil \frac{3}{2}\rceil \times 2=2\times 2=\boxed{4}$ Toh union 4 bytes ki hai, 3 nahi — 1 byte padding add ki jaati hai taaki union G ke arrays mein har short even address par rahe.

Dono members offset 0 se shuru hote hain — woh overlap karte hain. Toh tag aur d ka byte 0 same byte hai. d store karna tag overwrite karta hai; tag store karna d ka low byte corrupt karta hai. Size = sabse bada member double = 8, alignment 8, aur 8 pehle se 8 ka multiple hai, toh: $\text{sizeof(union H)}=\boxed{8}$ Struct se key contrast: ek struct H mein dono alag offsets par hote (0 aur 8, padding ke saath), total 16 bytes; union mein woh offset 0 share karte hain aur 8 lete hain. Unions ka yahi memory-saving point hai.

Union ke saare members offset 0 se shuru hote hain. Union ka size uske largest member ke barabar hota hai, alignment ke liye round up karke. Woh member padhna jo tumne nahi likha tumhe reinterpreted / garbage bits deta hai, converted value nahi. Ek tagged union union ko ek enum ke saath pair karta hai jo live member record karta hai.