Visual walkthrough — MISRA C — rules for safety-critical C code

The parent note said: "Only use bitwise ops on unsigned types where the bit pattern is standardized." That is the central result of MISRA C's type-safety rules. But why is the bit pattern of a signed number dangerous? This page rebuilds the whole argument from the ground up — from "what is a bit" all the way to "why (-1) >> 1 is a landmine" — one picture at a time.

We will earn every symbol before we use it. If you have never seen a bit, a shift, or two's complement, start at line one and you will be fine.

Prerequisites we will link but not assume: Embedded C Best Practices, Memory Safety, Static Analysis Tools. Parent: MISRA C parent (Hinglish).

Step 1 — What is a bit, and what is a "bit pattern"?

WHAT. A computer stores every number as a row of tiny switches. Each switch is either off (we write 0) or on (we write 1). One switch = one bit. A fixed-width row of these switches — say 8 of them — is a bit pattern.

WHY. Before we can talk about "shifting bits" or "the sign bit", we must see the row of switches literally. Every later step is just moving these switches around.

PICTURE. Below, an 8-bit row. Each cell is one bit. The number 13 lives here as the pattern 00001101.

Reading the row like ordinary base-10, but in base-2:

$\underset{128}{\underbrace{0}}\underset{64}{\underbrace{0}}\underset{32}{\underbrace{0}}\underset{16}{\underbrace{0}}\underset{8}{\underbrace{1}}\underset{4}{\underbrace{1}}\underset{2}{\underbrace{0}}\underset{1}{\underbrace{1}}$

• Each label under a bit is its place value (a power of two).
• Add up the place values wherever a 1 sits: $8+4+1=13$. That is the number.

Step 2 — What does the shift operator >> actually do?

WHAT. The operator >> (say "right shift") takes the whole row of bits and slides every bit one position to the right. Bits that fall off the right edge vanish. A new bit must appear on the left to fill the gap.

WHY. MISRA Rule 10.1 is about << and >> (and &, |, ^). To judge whether the rule is worth having, we must watch exactly what a shift does to the row — especially what fills the empty left slot, because that is where the danger hides.

PICTURE. Watch 00001101 (=13) become 00000110 (=6) under one right shift. The rightmost 1 falls off; a 0 slides in on the left.

The empty-left-slot question — what comes in on the left? — was easy here: a 0. Hold that thought. For unsigned numbers the answer is always 0, and that predictability is the whole point of the rule.

Step 3 — Where do negative numbers live? (Two's complement, the sign bit)

WHAT. A row of bits has no minus sign to spare. So to store negatives, hardware uses a convention called two's complement: the leftmost bit is reinterpreted as a negative place value. In 8 bits, the leftmost bit is worth $-128$ instead of $+128$.

WHY. Rule 10.1 forbids shifts on signed operands specifically. We cannot see the danger until we see how "signed" changes the meaning of the very same row of switches. Same switches, new rulebook.

PICTURE. The identical row, now with the leftmost place value flipped to $-128$. The number $-1$ is the pattern where every bit is 1.

Check that all-ones really is $-1$:

$\underset{-128}{\underbrace{1}}\underset{64}{\underbrace{1}}\underset{32}{\underbrace{1}}\underset{16}{\underbrace{1}}\underset{8}{\underbrace{1}}\underset{4}{\underbrace{1}}\underset{2}{\underbrace{1}}\underset{1}{\underbrace{1}}$

• The leftmost 1 contributes $-128$ (the sign bit "turned on").
• The other seven 1s contribute $64+32+16+8+4+2+1=127$.
• Total: $-128+127=-1$. ✔

So the pattern 11111111 is the number $-1$. Remember that; it is our trap in Step 5.

Step 4 — The fork in the road: two ways to fill the left slot

WHAT. When you right-shift a signed negative number, hardware designers face a choice for the incoming left bit:

• Logical shift: always slide in a 0.
• Arithmetic shift: slide in a copy of the sign bit (a 1 if the number was negative), so the number stays negative and behaves like true division.

WHY. This is the exact hinge of the whole rule. The C standard does not decide which one happens for signed types — it is left implementation-defined, meaning the compiler vendor picks. Two correct compilers can disagree. Same source code, different result.

PICTURE. Both forks drawn side by side for -1 >> 1. Left fork (logical) fills 0 and gives a huge positive number; right fork (arithmetic) fills 1 and gives $-1$ back.

The two forks side by side:

• Left branch: a 0 came in on top, killing the sign bit → result reads as $+127$ (on 8-bit; on 32-bit it becomes the giant $2147483647$).
• Right branch: a copy of the sign bit 1 came in → result stays $-1$.

Both are legal C. That ambiguity is not acceptable in a braking system.

Step 5 — The landmine in code: (-1) >> 1

WHAT. We combine everything. A programmer writes int result = (-1) >> 1; expecting "half of $-1$, rounded toward zero" — i.e. $0$, or on arithmetic hardware $-1$. But on a compiler that does logical shifts of signed types, they get $2147483647$ (the largest 32-bit signed value).

WHY. This is the concrete disaster Rule 10.1 prevents. A value expected to be near zero suddenly becomes over two billion. If that value feeds a loop bound, a memory index, or a timer, you have a hang, an out-of-bounds write (a Memory Safety breach), or a missed real-time deadline in an Real-Time Operating Systems (RTOS).

PICTURE. A number line showing the expected result ($-1$ or $0$, near the origin) versus the possible actual result ($2147483647$, off at the far right), with the gap labelled "silent catastrophe".

int32_t x = -1;
int32_t r = x >> 1;   /* Rule 10.1 VIOLATION: signed operand of >> */
/* r is -1 on one compiler, 2147483647 on another. Both are legal C. */

Step 6 — The MISRA fix: shift only unsigned operands

WHAT. MISRA C:2012 Rule 10.1 forbids bitwise and shift operators on operands of essentially signed type. The fix: make the operand unsigned. For unsigned types the C standard guarantees the left slot fills with 0 — the logical shift — on every compiler.

WHY. Removing the ambiguity restores predictability (a core MISRA principle): the same code gives the same bit pattern everywhere. Now the value is verifiable, testable, and safe to reason about with Formal Verification.

PICTURE. The unsigned world: only one fork exists. 11111111u (= 255) >> 1 always → 01111111 (= 127). No choice, no vendor gamble.

uint32_t x = 0xFFFFFFFFU;   /* the unsigned value 4294967295 */
uint32_t r = x >> 1;        /* Rule 10.1 COMPLIANT */
/* r is 0x7FFFFFFF = 2147483647 on EVERY compiler. Deterministic. */

Note that 0xFFFFFFFFU as unsigned means $4294967295$, and >> 1 gives $2147483647$ — a defined answer, unlike the signed trap in Step 5 even though the bit pattern looks similar.

Step 7 — Edge & degenerate cases (so nothing surprises you)

WHAT. Let us sweep the corners the rule also protects.

WHY. A rule you only understand in the "typical" case will bite you at the boundaries. MISRA's value is that it covers all of them uniformly by banning signed operands outright.

PICTURE. A small table of corner cases, each with its "signed = ambiguous / unsigned = defined" verdict.

The one-picture summary

Everything above collapses into one diagram: the same 8-bit row, right-shifted once, forking on signedness — unsigned always safe (one deterministic path), signed branching into a vendor gamble.