This page is the "run every case" workshop for Function pointers . The parent note built the ideas; here we exercise them until no scenario can surprise you. If a symbol shows up you don't recognise, it was defined in the parent — but we'll re-anchor the important ones as we go.
Prerequisites we lean on: Pointers in C , Arrays in C , void pointers , typedef , qsort and the C Standard Library , and the idea of Polymorphism .
Definition The one API we keep calling — re-anchoredThe standard-library sorter has this exact signature (from <stdlib.h>):
void qsort ( void * base , size_t nmemb , size_t size , int ( * compar)( const void * , const void * ));
base — pointer to the first element of the array to sort.nmemb — number of members (how many elements).size — the size in bytes of one element (usually sizeof(int) etc.).compar — a function pointer : your comparator, taking two const void * and returning an int whose sign tells qsort the order.
Every qsort example below plugs into these four slots.
Before working examples, let's list every kind of situation a function pointer can put in front of you. Think of this like the "all quadrants + zero + limits" checklist for angles — but for code. Each row is a case class ; every example below is tagged with the cell it fills.
#
Case class
What makes it tricky
Example that covers it
A
Declare + call a plain fn pointer
(*p) parentheses; two call syntaxesEx 1
B
Ascending sort via qsort (positive sign)
comparator returns positive
Ex 2
C
Descending sort (flipped sign)
comparator returns negative
Ex 2
D
Equal elements (zero case)
comparator returns 0 , stability
Ex 3
E
Degenerate input: array of size 0 or 1
callback may never fire
Ex 4
F
Dispatch table (array of fn pointers)
index selects behaviour
Ex 5
G1
Overflow trap (a-b)
subtraction returns wrong sign
Ex 6
G2
Signature mismatch (wrong type)
UB from calling through mismatched type
Ex 7
H
NULL / uninitialised pointer (degenerate)
calling garbage → crash
Ex 8
I
Real-world word problem
callback as "behaviour parameter"
Ex 9
J
Exam-style twist (pointer to fn returning pointer)
reading gnarly declarations
Ex 10
Intuition Why a matrix first?A function pointer's behaviour depends entirely on the sign the comparator returns , how many times the callback is invoked , and whether the pointer actually points at valid code . Those three axes generate every bug and every feature. Cover all cells → nothing left to surprise you.
Worked example Two ways to call the same pointerGiven:
int add ( int a , int b ) { return a + b; } int ( * p)( int , int ); p = add; What do p(3, 4) and (*p)(3, 4) each return, and are they different?
Forecast: Guess before reading — do the two forms give different numbers, or the same?
Read the declaration inside-out. int (*p)(int, int) = "p is a pointer to a function taking two ints and returning int."
Why this step? You must confirm the pointer's type matches add exactly, else the call is undefined behaviour.Assign. p = add; — the name add decays to its address. p = &add; is identical.
Why this step? A function name in an expression turns into "the address where its code starts," so no & is needed (though it's allowed).Call plainly. p(3,4) → add runs with a=3, b=4 → 3+4 = 7.
Why this step? To call, C needs a function; p decays to the function it points at.Call with explicit deref. (*p)(3,4) → *p gives the function, which immediately decays back to a pointer, so C treats it identically → 7.
Why this step? To prove the two syntaxes are the same, not a trick.
Verify: Both return 7. Sanity: 3+4=7. ✓ Units: two ints in, one int out — matches the declared type.
The figure below shows the single rule that drives every sort: qsort reads only the sign of your comparator. Three coloured buckets — teal for negative (first goes before second), plum for zero (equal), burnt orange for positive (first goes after second) — and an orange arrow tracing the worked case x=3, y=1 → +1. Keep this picture in mind whenever a comparator returns a number.
qsort call, opposite orders
int cmp_asc ( const void * a , const void * b ) { int x = * ( const int* )a, y = * ( const int* )b; return (x > y) - (x < y); } int cmp_desc ( const void * a , const void * b ) { int x = * ( const int* )a, y = * ( const int* )b; return (y > x) - (y < x); } int arr [] = { 3 , 1 , 2 }; Run qsort(arr, 3, sizeof(int), cmp_asc); then (fresh copy) cmp_desc. What are the two results?
Forecast: Predict both final arrays before reading on.
Decode the comparator return. qsort only reads the sign : negative means "first arg goes before second," 0 means equal, positive means "first goes after."
Why this step? The sign is the ordering rule — look at the figure's three coloured buckets.Ascending, compare 3 vs 1. x=3, y=1: (3>1)-(3<1) = 1-0 = +1 → positive → 3 goes after 1.
Why this step? Positive sign pushes the bigger value rightward → smallest-first order.Full ascending pass yields {1, 2, 3}.
Why this step? Every pairwise comparison returns "+1 when left is bigger," so values climb.Descending swaps the roles of x and y. For 3 vs 1: (y>x)-(y<x) = (1>3)-(1<3) = 0-1 = -1 → negative → 3 goes before 1.
Why this step? Flipping x,y flips every sign, reversing the whole order — the only change needed.Full descending pass yields {3, 2, 1}.
Verify: ascending {1,2,3}, descending {3,2,1}. Sanity: descending is the exact reverse of ascending. ✓ Same qsort, only the passed function differed — the callback carried the behaviour.
Worked example What happens when comparator returns 0?int arr [] = { 5 , 5 , 2 , 5 }; qsort (arr, 4 , sizeof ( int ), cmp_asc); What is the sorted array, and what does the comparator return when it compares two 5s?
Forecast: Guess the final array and the return value for 5 vs 5.
Compute the equal case. x=5, y=5: (5>5)-(5<5) = 0 - 0 = 0.
Why this step? The zero return is the third bucket — "these two are interchangeable; don't reorder them for their sake."Place the lone 2. Every comparison of 2 against a 5 gives (2>5)-(2<5) = 0-1 = -1 → 2 sorts to the front.
Why this step? Negative means "goes before," so the smallest lands first.The three 5s stay grouped. Since 5 vs 5 returns 0, they cluster together after the 2.
Why this step? A 0 return means qsort has no reason to separate them.
Verify: result {2, 5, 5, 5}. Sanity: one 2 (smallest) leads, three 5s follow, count preserved (4 elements). ✓
0 means "swap"
It doesn't — 0 means treat as equal / leave order be . Note: standard qsort is not guaranteed stable , so the relative order of the three 5s is unspecified — but since they're identical, you can't tell. ✓
Worked example Does the callback even run?int a1 [] = { 42 }; // size 1 (valid C) int a3 [] = { 7 , 8 , 9 }; // we'll pass only the first 0 of these qsort (a3, 0 , sizeof ( int ), cmp_asc); // nmemb = 0: sort "nothing" qsort (a1, 1 , sizeof ( int ), cmp_asc); // nmemb = 1 (Note: standard C has no zero-length array literal like int a0[] = {};, so we model "size 0" by passing nmemb = 0 on a real array — qsort simply treats it as "sort the first 0 elements.")
How many times is cmp_asc called in each case, and what are the arrays afterward?
Forecast: Guess the number of comparator calls for nmemb = 0 and nmemb = 1.
Count comparisons needed. To decide an order you must compare at least two elements. With nmemb = 0 or nmemb = 1 there is no pair.
Why this step? No pair → nothing to compare → the callback fires 0 times .Result stays put. Nothing to reorder: with nmemb=0 a3 is untouched ({7,8,9}), and a1 stays {42}.
Why this step? A sort of ≤1 element is already sorted — the identity case, like the limiting value in a formula.
Verify: comparator calls = 0 for both; a1 = {42}; a3 unchanged. Sanity: a 1-element list is trivially sorted; a well-written comparator never being called means no NULL-deref risk here either. ✓
Recall Why is this the "limiting value" of sorting?Just as an angle formula must behave at 0 nmemb ≤ 1 → 0 comparisons → array unchanged.
The figure below draws the dispatch table as three top slots (ops[0], ops[1], ops[2]), each holding a code address, with a coloured arrow pointing down to the actual function body (add → a+b in teal, sub → a-b in orange, mul → a*b in plum). The caption traces ops[1](10,4) → sub(10,4) → 6. Read it as "index picks a wire, the wire runs code."
Worked example Index into behaviourint add ( int a , int b ){ return a + b;} int sub ( int a , int b ){ return a - b;} int mul ( int a , int b ){ return a * b;} int ( * ops [ 3 ])( int , int ) = { add, sub, mul }; Evaluate ops[0](10,4), ops[1](10,4), ops[2](10,4), and (*ops[2])(10,4).
Forecast: Predict all four numbers.
Read the array type. int (*ops[3])(int,int) = "array of 3 pointers to int(int,int)." The [3] binds after (*...), so it's an array of pointers , not a pointer to an array.
Why this step? Mis-reading this is the classic exam trap; the figure shows three slots each holding a code address.Index selects a function. ops[0] → add, ops[1] → sub, ops[2] → mul.
Why this step? The index is the opcode — O(1) dispatch replaces an if/else chain.Call each: add(10,4)=14, sub(10,4)=6, mul(10,4)=40.
Why this step? Each slot carries different behaviour; only the index changed.Explicit deref of a slot. (*ops[2])(10,4) = mul(10,4) = 40 — identical to ops[2](10,4).
Why this step? Confirms the deref-equivalence rule from Ex 1 still holds inside arrays.
Verify: 14, 6, 40, 40. Sanity: 10+4=14, 10-4=6, 10*4=40. ✓ This is exactly how bytecode interpreters route opcodes.
Worked example The comparator that silently breaksA student writes return a - b; inside a comparator and tests with:
int a = 2000000000 ; // ~2e9 int b = - 2000000000 ; // ~-2e9 With 32-bit int (max ≈ 2147483647), what does the mathematical value a - b want to be, and why is computing it dangerous?
Forecast: Guess whether a - b gives a correct positive result.
True mathematical value. a − b = 2000000000 − ( − 2000000000 ) = 4000000000 Why this step? We need the ideal answer to compare against what a 32-bit int can actually hold.Compare to the int ceiling. 4000000000 > 2147483647 cannot fit in a signed 32-bit int.
Why this step? In standard C, computing a signed result that exceeds INT_MAX is undefined behaviour — not a guaranteed wrap. The program may produce a garbage value, a wrong sign, or trap; the standard makes no promise . That unpredictability is exactly why the comparator is broken.Concrete symptom. On typical two's-complement hardware you often see a wrapped-looking negative like -294967296 (i.e. 4000000000 − 2 32 not the correct positive sign the sort needs.
Why this step? The comparator would then claim "a < b" when truly a > b, silently corrupting the sort.The safe form. (a>b)-(a<b) = (1)-(0) = +1 → correctly positive, no arithmetic on the values themselves, no overflow, no UB.
Why this step? It computes the sign directly from booleans (each 0 or 1), which can never overflow.
Verify: true value 4000000000 overflows INT_MAX = 2147483647 (UB in C); safe form = +1 (correct). Sanity: 2e9 really is greater than -2e9, so any correct comparator returns positive. ✓
Worked example "Addresses are all the same size" — the fatal assumptiondouble scale ( double x ) { return x * 2.0 ; } // takes/returns double int ( * p)( int ); // pointer to int(int) p = ( int ( * )( int )) scale; // force-cast the address in int r = p ( 5 ); // call through the WRONG type Is this defined? What actually goes wrong at the call?
Forecast: Guess — since scale's address fits in p, will p(5) just work?
The address does copy fine. A function's address is just a number; the cast in p = (int(*)(int))scale; compiles.
Why this step? This is why the mistake feels safe — the assignment doesn't complain.But the type is the calling contract. int(*)(int) tells the CPU: "push one int argument, and read the return value out of the integer register." scale expects a double in a floating-point register and returns a double from one.
Why this step? The type — not the address — decides how bytes are passed and read back . Mismatch means the machine reads the wrong registers.Calling through the mismatched pointer is undefined behaviour. p(5) may return garbage, corrupt the stack, or crash. The C standard says calling a function through a pointer of an incompatible type is UB — full stop.
Why this step? There is no "usually works" here; you cannot predict or rely on any output.The fix. Never cast a function pointer to a different signature to call it. Match return type and every parameter exactly : use double (*p)(double); p = scale;.
Why this step? A matching type restores the correct calling contract.
Verify: the assignment compiles (address fits); the call p(5) is UB (no defined result). Sanity check the correct version instead: scale(5.0) = 5.0 * 2.0 = 10.0, which is what you get only through a properly-typed double(*)(double) pointer. ✓
Worked example The crash caseint ( * p)( int , int ); // uninitialised — holds garbage // ... p never assigned ... int r = p ( 1 , 2 ); // ?? What happens, and what's the disciplined fix?
Forecast: Guess the outcome of calling p here.
Diagnose the value of p. An uninitialised local pointer holds an indeterminate bit pattern — some random address.
Why this step? Calling means "jump to this address and execute." A garbage address points at data, unmapped memory, or nowhere.The call. p(1,2) transfers control to that garbage address → undefined behaviour , typically a segmentation fault / crash.
Why this step? There's no valid function there; the CPU executes nonsense or hits a protection fault.Fix step 1 — initialise. int (*p)(int,int) = NULL; gives a known invalid value.
Why this step? NULL is a sentinel you can test for, unlike random garbage.Fix step 2 — guard. if (p) r = p(1,2); so you never call through NULL.
Why this step? A checked NULL turns a crash into a controlled skip.
Verify: uninitialised call → UB/crash (not a value we can compute — that's the whole danger). Fixed pattern: p == NULL → skip → no call. Sanity: the guard reduces to if (p != NULL). ✓
Worked example A thermostat with a "behaviour knob"A heating library exposes:
// calls the callback once per reading, passing the temperature in °C void monitor ( int * readings , int n , void ( * on_reading)( int )); You want it to print an alert only when temperature exceeds 30°C . Readings: {22, 31, 18, 45}. How many alerts print?
Forecast: Guess how many alerts fire for {22, 31, 18, 45}.
Write the callback (your behaviour).
void alert ( int t ) { if (t > 30 ) printf ( "ALERT %d\n " , t); } Why this step? The library owns the timing (once per reading); you own the action . This is the callback split — behaviour as data.Hand it over. monitor(readings, 4, alert); passes alert's address (name decays).
Why this step? monitor will "call you back" on each reading without knowing what your code does.Trace the four calls. 22→ no (22≤30); 31→ alert ; 18→ no; 45→ alert .
Why this step? Only readings strictly above 30 trigger the printf.Count. Two readings satisfy t > 30.
Why this step? That's the answer the question asks for.
Verify: alerts printed = 2 (for 31 and 45). Sanity: readings > 30 are exactly {31, 45} → count 2. ✓ Swap alert for a log() callback and behaviour changes with zero edits to monitor — the point of callbacks.
Worked example Read the scary declarationint * ( * f)( int , int ); Describe exactly what f is. Then contrast it with int (*g)(int,int).
Forecast: Is f a function returning a pointer, a pointer to a function, or something else? Guess first.
Find the identifier. It's f.
Why this step? Reading C declarations starts at the name and works outward.Innermost binding. (*f) — the parentheses make f a pointer first (star hugs the name).
Why this step? Without the parens (int *f(int,int)) it'd be "function returning int*" — the parens force pointer-first .Apply the parameter list. (int,int) → the thing f points to is a function taking (int,int) .
Why this step? After establishing "pointer to function," the arg list tells us its signature.Apply the return type. int * → that function returns a pointer to int .
Why this step? The leftmost int * is the return type of the pointed-at function.Full reading: f is a pointer to a function taking two ints and returning int* .
Why this step? Assemble the outward-read pieces into one English sentence.Contrast. int (*g)(int,int) returns a plain int; f returns an int*. Different return types → incompatible pointers ; you cannot assign one to the other.
Why this step? Return type is part of the type contract (Ex 7) — mismatched return types make the two pointers non-interchangeable.
Verify: f : int* (*)(int,int); g : int (*)(int,int). Sanity check with the typedef trick — typedef int* (*RetPtr)(int,int); then RetPtr f; reads cleanly and confirms the return type is int*. ✓
Recall Matrix coverage checkWhich cells did we cover, A–J? ::: All of them: A(Ex1), B&C(Ex2), D(Ex3), E(Ex4), F(Ex5), G1(Ex6), G2(Ex7), H(Ex8), I(Ex9), J(Ex10). No cell left unshown.
Sign, count, aim. Every function-pointer scenario is one of: what sign does the comparator return (order), how many times is the callback called (0 for degenerate inputs), and does the pointer aim at real code with the right type (else crash / UB).
