Foundations — MISRA C — rules for safety-critical C code

5.5.19 · D1 · Coding › Embedded Systems & Real-Time Software › MISRA C — rules for safety-critical C code

Isse pehle ki hum parent note MISRA C ko padh bhi sakein, hume — bilkul scratch se — har woh word aur symbol build karna hoga jo woh quietly assume karta hai ki tum pehle se jaante ho. Yeh hum bottom-up karte hain: har idea usse pehle waale par tika hota hai.

1. "Memory" kya hai? (sab cheez ke peeche ka picture)

C ki saari fears ek jagah rehti hain: memory. Toh hum pehle usey draw karte hain.

Figure dekho. Boxes ki row memory hai. Har box ke neeche chhota number (0, 1, 2, 3 …) uska address hai — uska permanent house number. Box ke andar ki value data hai. Yahi ek picture woh stage hai jis par har MISRA rule play out hota hai.

Yeh topic ko kyun chahiye: MISRA ka poora kaam hai tera program galat box padhne ya likhne se rokna. "Buffer overflow" ya "dangling pointer" tum tab tak samajh nahi sakte jab tak tum pehle boxes nahi dekh lete.

2. Bits aur byte

Notation $2^8$ ka matlab hai "2 ko 8 baar khud se multiply karo" — har extra lamp double kar deta hai kitne patterns possible hain, kyunki har lamp independently ek off/on choice add karta hai.

Yeh topic ko kyun chahiye: bitwise operators (&, |, <<, >>) ke baare mein rules inhi lamps ko directly manipulate karte hain. Agar tum 8 lamps ki row picture nahi karte, toh "bits ko right shift karna" meaningless hai.

Figure mein, upar ki row ek byte hai jisme number 42 ka pattern stored hai. Neeche ki row same lamps ko ek jagah right shift karke dikhata hai — har lamp right slide karta hai, ek edge se gir jaata hai, left par ek naya lamp aata hai. Kaunsa lamp left par aata hai — yahi MISRA Rule 10.1 ka poora drama hai (D2 mein zyada).

3. "Type" — woh label jo kehta hai ek box ko kaise padho

Boxes sirf numbers rakhte hain. Lekin kya 0xFF number 255 hai, ya number −1, ya koi letter? Type decide karta hai.

Yahi kai MISRA type rules ka core hai: ek signed label aur unsigned label ko mix karna computer ko same lamps ko silently reinterpret karne par majboor karta hai, jo $-1$ ko $4,294,967,295$ mein badal sakta hai.

4. Two's complement — negatives kaise store hote hain

Parent note kehta hai "two's complement representation" jaise tum jaante ho. Aaiye isse earn karte hain.

Yeh tool kyun aur koi nahi? Kyunki two's complement ke saath, ordinary addition circuitry negatives ke liye bhi kaam karti hai — koi special "subtract mode" hardware ki zaroorat nahi. Yahi efficiency ki wajah se har real CPU isse use karta hai.

Yeh topic ko kyun chahiye: MISRA Rule 10.1 signed value ko right-shift karna ban karta hai kyunki jab sign lamp 1 ho, standard fix nahi karta ki left par kaunsa lamp pull hoga — yeh implementation-defined hai. Two's complement hi woh reason hai ki yeh ambiguity exist bhi karti hai.

5. Pointer — ek box jiska value ek address hai

Ab hum C ka sabse dangerous idea define kar sakte hain.

Figure follow karo. Left par box p data nahi rakhta — yeh address 8 rakhta hai (red arrow p se box 8 ki taraf point karta hai). *p likhne ka matlab hai "jahan arrow land kare wahan jao aur woh box use karo". Yahi arrow hai jo galat box ki taraf point kar sakta hai.

Yeh topic ko kyun chahiye: har pointer rule (18.1, 18.7) is arrow ko kisi valid jagah point karte rehne ke baare mein hai.

6. Array — ek naam share karne waale boxes ka run

Pointer arithmetic (topic ka Rule 18.1) isi par built hai: p + 1 address mein 1 add nahi karta — yeh arrow ko ek poore box ke bytes forward move karta hai, yaani sizeof(type) bytes, exactly next array element par land karta hai.

$p+n=\text{addr}+n\times \text{sizeof(type)}$

Yahan sizeof(type) ka matlab sirf "is type ki ek value kitne boxes occupy karti hai" hai. Last element ke aage jaana tumhe aisi memory mein le jaata hai jo tumhari nahi — exactly wahi catastrophe jo Rule 18.1 forbid karta hai.

7. Static vs dynamic memory (stack vs heap)

Yeh topic ko kyun chahiye: Rule 21.3 safety code mein heap ko poori tarah ban karta hai, kyunki brake controller mein tum "120 km/h par out of memory" ka risk nahi le sakte. Memory Safety samajhna yahan se shuru hota hai.

8. Undefined / unspecified / implementation-defined behaviour

Parent note inhi teen phrases par constantly lean karta hai. Yeh ek jaise nahi hain.

Yeh topic ko kyun chahiye: MISRA ka poora mission hai teeno par reliance hatana, taaki same source code har compiler par identically behave kare — yahi predictability principle hai.

9. Static analysis & decidability — rules kaise check hote hain

Yeh topic ko kyun chahiye: MISRA deliberately zyaatar rules decidable likhta hai taaki machine unhe enforce kar sake — yahi hai jo poore subset ko practical banata hai.

Prerequisite map

Har arrow kehta hai "left wala box samjho pehle, tabhi right wala box sense banega". Saari raahein MISRA C tak jaati hain.

Related vault topics

• Memory Safety — woh property jo MISRA ke pointer/array rules protect karte hain.
• Static Analysis Tools — woh machines jo decidable rules enforce karti hain.
• Real-Time Operating Systems (RTOS) — kyun timing predictable honi chahiye (koi heap surprises nahi).
• ISO 26262, DO-178C, IEC 62304 — automotive/aerospace/medical standards jo MISRA jaisi rulebooks require karte hain.
• Formal Verification — correctness prove karna, restricted subset se feasible banta hai.

Equipment checklist

Right side cover karo; reveal karne se pehle answer kar sakte ho?