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

Before we can even read the parent note on MISRA C, we need to build — from nothing — every word and symbol it quietly assumes you already know. We do this bottom-up: each idea rests on the one before it.

1. What is "memory"? (the picture behind everything)

Everything C fears lives in one place: memory. So we draw it first.

Look at the figure. The row of boxes is memory. The small number under each box (0, 1, 2, 3 …) is its address — its permanent house number. The value inside a box is the data. This one picture is the stage on which every MISRA rule plays out.

Why the topic needs this: MISRA's whole job is stopping your program from reading or writing the wrong box. You cannot understand "buffer overflow" or "dangling pointer" without first seeing the boxes.

2. Bits and the byte

The notation $2^8$ means "2 multiplied by itself 8 times" — each extra lamp doubles how many patterns are possible, because each lamp independently adds an off/on choice.

Why the topic needs this: rules about bitwise operators (&, |, <<, >>) manipulate these lamps directly. If you don't picture the row of 8 lamps, "shifting the bits right" is meaningless.

In the figure, the top row is a byte holding the pattern for the number 42. The bottom row shows the same lamps shifted one place right — every lamp slides right, one falls off the edge, a new lamp appears on the left. Which lamp appears on the left is the whole drama of MISRA Rule 10.1 (more in D2).

3. A "type" — the label that says how to read a box

Boxes just hold numbers. But is 0xFF the number 255, or the number −1, or a letter? The type decides.

This is the heart of many MISRA type rules: mixing a signed label and an unsigned label makes the computer silently reinterpret the same lamps, which can turn $-1$ into $4,294,967,295$.

4. Two's complement — how negatives are stored

The parent note says "two's complement representation" as if you know it. Let's earn it.

Why this tool and not another? Because with two's complement, ordinary addition circuitry just works for negatives too — no special "subtract mode" hardware needed. That efficiency is why every real CPU uses it.

Why the topic needs it: MISRA Rule 10.1 bans right-shifting a signed value because when the sign lamp is 1, the standard doesn't fix which lamp gets pulled in on the left — it's implementation-defined. Two's complement is the reason that ambiguity even exists.

5. Pointer — a box whose value is an address

Now we can define the single most dangerous idea in C.

Follow the figure. The box p on the left doesn't hold data — it holds the address 8 (the red arrow points from p to box 8). Writing *p means "go to where the arrow lands and use that box". This arrow is the thing that can point at the wrong box.

Why the topic needs it: every pointer rule (18.1, 18.7) is about keeping this arrow pointing somewhere valid.

6. Array — a run of boxes sharing one name

Pointer arithmetic (the topic's Rule 18.1) is built on this: p + 1 doesn't add 1 to the address — it moves the arrow forward by one whole box's worth of bytes, i.e. sizeof(type) bytes, landing exactly on the next array element.

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

Here sizeof(type) just means "how many boxes one value of this type occupies". Moving past the last element lands you in memory you don't own — the exact catastrophe Rule 18.1 forbids.

7. Static vs dynamic memory (stack vs heap)

Why the topic needs it: Rule 21.3 bans the heap entirely in safety code, because in a brake controller you cannot risk "out of memory at 120 km/h". Understanding Memory Safety starts here.

8. Undefined / unspecified / implementation-defined behaviour

The parent note leans on these three phrases constantly. They are not the same.

Why the topic needs it: MISRA's entire mission is to remove reliance on all three, so identical source code behaves identically on every compiler — the predictability principle.

9. Static analysis & decidability — how rules get checked

Why the topic needs it: MISRA deliberately writes most rules to be decidable so a machine can enforce them — that is what makes the whole subset practical.

The prerequisite map

Every arrow says "you must understand the box on the left before the box on the right makes sense". All roads lead to MISRA C.

Related vault topics

• Memory Safety — the property MISRA's pointer/array rules protect.
• Static Analysis Tools — the machines that enforce decidable rules.
• Real-Time Operating Systems (RTOS) — why timing must be predictable (no heap surprises).
• ISO 26262, DO-178C, IEC 62304 — the automotive/aerospace/medical standards that require rulebooks like MISRA.
• Formal Verification — proving correctness, made feasible by the restricted subset.

Equipment checklist

Cover the right side; can you answer before revealing?