restrict keyword — aliasing hint: Foundations

Before you can understand that promise, you must be able to read every symbol the parent note throws at you. This page builds each one from nothing, in an order where each piece leans on the one before it. Nothing here assumes you have written C before.

0. The building blocks, in order

We will assemble the meaning of this line — the star of the whole topic — one piece at a time:

void add(int * restrict a, const int * restrict b, const int * restrict c, int n);

By the end of this page every token in it will be a picture in your head.

1. Memory = a long street of numbered boxes

Figure — restrict keyword — aliasing hint

Look at the figure. The row of boxes is memory. Under each box is its address (0, 1, 2, 3, …) — a plain counting number. Inside each box is a value (the data). Address and value are two different things: address = "which box", value = "what's in the box". Keep them apart in your mind; everything else depends on it.

Why the topic needs this: restrict is a promise about which boxes two pointers can touch. If you don't picture memory as numbered boxes, "overlap" and "aliasing" are just words. See Pointers in C for the full story.

2. A variable is a named box

x — the name you use to talk about the box.
5 — the value currently inside.
The box still has an address underneath (say, box #12), even though you usually don't care what it is.

Why the topic needs this: pointers store the address of one of these boxes. No named boxes → nothing for a pointer to point at.

3. `&` — "the address of"

Why the topic needs this: the parent's decision rule writes \&p[i] \ne \&q[j] — that & is exactly this: "the address of element i" must not equal "the address of element j". It's comparing locations, asking "are these two boxes the same box?".

4. A pointer is a slip of paper holding an address

In the figure, p is drawn as a little card with an arrow. The arrow's tail is the pointer; the arrowhead lands on the box it points at. The * in int *p reads as "is a pointer to" — so int *p = "p is a pointer to an int box."

Why the topic needs this: restrict is a qualifier you attach to pointers. If a pointer isn't a slip-of-paper-holding-an-address in your head, "two pointers to the same memory" has no picture.

5. `*p` — "follow the arrow" (dereference)

p = the address (the slip of paper).
*p = the value living at that address (what's in the box the arrow lands on).

Why the topic needs this: the parent's *a, *b, *factor are all dereferences — reading/writing the box at the far end of the arrow. The whole speed argument is about how often the compiler must re-walk these arrows.

6. Arrays and `p[i]` — a whole row of boxes with one starting arrow

The figure shows one array laid out, with a[0], a[1], a[2], a[3] labelled. The key insight drawn in pink: a + 1 (or a pointer arr+1) is just an arrow that starts one box later. So two pointers into the same row — one at a, one at a+1 — point at overlapping stretches of boxes. That overlap is the whole danger the parent's Example 2 warns about.

Why the topic needs this: the parent's fatal example copy(arr+1, arr, 3) overlaps precisely because arr and arr+1 are two arrows into one shared row. You now see why they collide.

7. Aliasing — two arrows landing on the same box

Two cases, side by side in the figure:

Left (blue, safe): a and b point at separate rows. No box is shared. Writing through a can never disturb b. This is the world where restrict is a true promise.
Right (pink, aliasing): a and b overlap. A store through a silently changes a box b will later read. Here restrict would be a lie.

Why the topic needs this: restrict is literally the assertion "the left picture is true, not the right one." Everything in Pointer aliasing flows from this split.

8. `const` — "I won't change what's in these boxes" (a different promise!)

Why the topic needs this: the parent's signature stacks both qualifiers. You must read const int * restrict b as two separate promises glued to one pointer: (read-only) and (no aliasing).

9. `void`, `int`, `n` — the leftover plumbing

Small pieces, quickly, so nothing in the signature is a mystery:

void (as a return type) = "this function hands nothing back." It just does its work.
int = a box holding a whole number.
n = an ordinary int variable used as the count — how many boxes the loop walks.
for (int i = 0; i < n; i++) = "let i step from 0 up to n-1, one at a time." It's the loop that visits each box.

Why the topic needs this: the speed win from restrict only shows up inside loops, because that's where the compiler repeats work many times. No loop, no dramatic payoff.

10. "Qualifier" vs "keyword", and undefined behaviour

Why the topic needs this: the entire risk of restrict is that lying triggers UB, and the compiler won't warn you. restrict arrived in C99 standard features; before that, C had no way to give this hint at all.

Prerequisite map

Equipment checklist

Cover the right side and test yourself. If any answer is fuzzy, re-read that section before opening the main note.

An address vs a value — which is "which box" and which is "what's inside"?

Address = which box (its number); value = what's inside the box.

What does &x give you?

The address (location) of the box named x, not its contents.

In int *p, what does the * mean?

"is a pointer to" — p is declared to hold the address of an int box.

In *p = 9;, what does the * mean now?

"follow the arrow" (dereference) — go to the box p points at and store 9 there.

What is a[i] in box-terms?

The box i steps to the right of the array's first box.

Why do arr and arr+1 overlap?

They are two arrows into the same row; arr[1] and (arr+1)[0] are literally the same box.

Define aliasing in one sentence.

Two different pointers that can reach the same box, so writing via one changes what the other reads.

Does const say anything about overlap?

No — const is about not modifying; overlap/aliasing is restrict's job.

Is restrict a keyword or a qualifier?

Both — it's a keyword, and specifically a type qualifier (C99).

What is undefined behaviour?

A situation where the C standard promises nothing — may work, crash, or corrupt data, often only at high optimization.

Connections

Hinglish version →
Pointers in C
const qualifier
Pointer aliasing
memcpy vs memmove
Undefined behaviour in C
C99 standard features