Foundations — Functions — declaration vs definition, prototypes, call by value

Before you can read the parent note comfortably, you must own every little symbol it throws around. This page collects them in build order: each one only uses ideas already explained above it. If you meet a symbol on the parent page and feel a flicker of "wait, what is that?" — it is defined here.

0. The absolute atoms: what a "program" even is

Why the topic needs this: the parent note keeps saying "the compiler reads top-to-bottom, once." That single fact is the reason prototypes exist. So we anchor it first.

The red scanner in the figure only moves downward. When it reaches a line that uses a name it has never seen, it cannot look ahead to find it later — it must already know that name. Hold that image; it explains the whole "declare before you call" rule.

1. Types — the "shape" of a value

Why needed: every function has a return type (the shape of what comes out) and its parameters have types (the shape of what goes in). Without types the compiler wouldn't know how many bytes to copy.

2. Variable — a named box

Why needed: the parent's whole swap/square/next story is about which box gets changed — the caller's box, or a fresh copy box inside the function.

3. Function — the reusable machine

The figure names each part on the machine. Learn these four words — return type, name, parameters, body — because the parent note's "declaration vs definition" distinction is entirely about which of these parts are present.

4. Parameter vs Argument — the two ends of a call

These two words sound the same and get mixed up forever. Nail them now.

Why needed: "call by value" means the argument's value is copied into the parameter. You cannot understand that sentence until these two words are separate in your head.

5. The three verbs: ;, {}, and the difference they make

Now the pivotal parent idea falls out with zero new machinery:

So "declaration vs definition" is not two mysterious concepts — it is literally the same signature followed by either a semicolon or a body. That is why the parent can say "a definition is automatically also a declaration": the definition contains the whole signature, so it also fulfils the promise a bare declaration would make.

6. Return — the output chute

Why needed: the return type from §1 is exactly the shape of the thing that comes down this chute. void functions have no chute — they return nothing.

7. Copying — the heart of "call by value"

Now every atom is in place to explain the topic's soul.

The yellow arrow in the figure is a copy, not a wire. There is no live connection back to v. That is precisely why the parent's swap fails: swap shuffles its copies x and y, but the copy-arrows were one-way, so a and b never move.

8. Address & pointer — the escape hatch (preview only)

You will need these on the parent page's swap fix, so here is just enough to recognise them.

Full treatment is in Pointers in C. The parent note's key twist — passing a pointer is still call by value — makes sense now: you copy the address slip (a value!), but the slip still points home.

The prerequisite map

Each box only uses ideas from the boxes feeding into it — which is exactly the order this page introduced them.

Equipment checklist

Test yourself: cover the right side and answer before revealing.

Connections

• Yeh note Hinglish mein →
• Stack and Function Call Mechanism — where the copied parameters actually live.
• Pointers in C — the & / * escape hatch, in full.
• Scope and Lifetime of Variables — why the copy-box vanishes on return.
• Header Files and Separate Compilation — why declarations live apart from definitions.
• Arrays as Function Arguments · Recursion — next stops once these atoms are solid.