Pointers Debugging Exercises (10)

← Module home · Work each in the debugging protocol: reproduce → form hypotheses → instrument → fix → reflect. Here the protocol gains one step, always first: draw the diagram of what the code thinks is true.

Format. Each program compiles (unless stated) but misbehaves or crashes. Hint ladders are collapsible — expand one rung at a time. Fix-list summary at the end. ⚠️ These are pencil-and-machine exercises: hand-trace every one before running it, and run the crashy ones knowing exactly why they crash.

D1 — The switcheroo (the two jobs confused)

int main() {
    int a = 1, b = 2;
    int* p = &a;
    *p = &b;        // intent: make p point at b
    std::cout << *p << '\n';
}
// Expected: 2.   Compiler: ERROR (or worse, if it slips through on old compilers).

Reflection. Every pointer statement is one of the two jobs. Say which one you mean out loud, then write it.

D2 — The promise not kept (uninitialized dereference)

int main() {
    int* p;
    int x = 42;
    *p = x;          // "store x somewhere" — where?
    std::cout << *p;
}

Expected: 42. Observed: sometimes 42, sometimes garbage, sometimes a crash — never reliably anything.

Reflection. “It printed 42!” is not evidence — undefined behaviour can imitate correctness. Draw the arrow: if it points at garbage in the diagram, the program is wrong however it behaves.

D3 — The unguarded helper (null accepted, dereferenced anyway)

void setTo(int* target, int value) {
    *target = value;      // crashes when called as setTo(nullptr, 5)
}

int main() {
    int* p = nullptr;     // "no target yet" — a NORMAL pointer state
    setTo(p, 5);
}

void setTo(int* target, int value) {
    if (target == nullptr) return;   // or report the refusal
    *target = value;
}

Reflection. The signature is a contract. int* promises maybe nothing — so guard. int& promises always there — so don’t. Choose the one that matches reality.

D4 — The leaky loop (re-point without release)

int main() {
    for (int i = 0; i < 1000; i = i + 1) {
        int* p = new int(i);
        if (i % 2 == 0) p = nullptr;   // "clean up" — or so the author thought
    }
    std::cout << "done\n";
}

Expected (by the author): tidy cleanup. Observed: memory use climbs by ~1000 ints; nothing crashes.

for (int i = 0; i < 1000; i = i + 1) {
    int* p = new int(i);
    // ... use p ...
    delete p;          // release BEFORE the arrow is lost
    p = nullptr;
}

Reflection. “Setting to null” is cleanup of the pointer, never of the box. delete frees boxes; = nullptr tames arrows. Different objects, different verbs.

D5 — The use-after-free (dangling read)

int main() {
    int* p = new int(42);
    delete p;
    if (*p == 42)                 // "just checking..." — checking WHAT?
        std::cout << "still there\n";
    else
        std::cout << "changed\n";
}

Expected: neither — the program’s behaviour is undefined. Observed: often prints “still there” today — and corrupts or crashes next week after an unrelated edit.

Reflection. The same-line idiom is not ceremony — it converts the worst bug family (silent, delayed) into the best failure mode (loud, immediate).

D6 — The return of the local (dangling by function exit)

int* makeCounter() {
    int count = 0;
    return &count;       // author: "hand the counter up to the caller"
}

int main() {
    int* c = makeCounter();
    *c = *c + 1;         // "increment the counter"
    std::cout << *c << '\n';
}

Expected: 1. Observed: garbage, or a crash, or 1 — with a compiler warning (address of stack memory associated with local variable 'count' returned) that the author ignored.

Reflection. Heap boxes outlive functions; stack boxes don’t. If you need the heap only to survive a return, first check whether a copy is simpler (Module rule 5).

D7 — The crossed wires (new[] with delete)

int main() {
    int* data = new int[10];
    for (int i = 0; i < 10; i = i + 1) data[i] = i;
    delete data;      // one character off
    data = nullptr;
    std::cout << "ok\n";
}

Expected: clean. Observed: usually “ok” — and the heap’s bookkeeping for arrays is now quietly damaged; crashes appear later, in unrelated allocations.

Reflection. “It ran fine” is exactly how heap corruption behaves — the damage surfaces elsewhere, later. Pairs rules exist because the compiler can’t check this one for you.

D8 — The straying pointer (out-of-bounds arithmetic)

int main() {
    int* data = new int[5];
    for (int i = 0; i < 5; i = i + 1) data[i] = i * i;
    int* p = data;
    for (int i = 0; i <= 5; i = i + 1) {     // spot it...
        std::cout << *p << ' ';
        p = p + 1;
    }
    delete[] data;
    data = nullptr;
}

Expected: 0 1 4 9 16 — five values. Observed: six values — the sixth read from memory past the block.

Reflection. Pointer arithmetic has no bounds checking whatsoever — the loop condition is the only fence. Draw the block; count the dereferences.

D9 — The double release (two owners, one box)

void process(int* data, int n) {
    int total = 0;
    for (int i = 0; i < n; i = i + 1) total += data[i];
    std::cout << total << '\n';
    delete[] data;                 // "helpfully" cleaning up
}

int main() {
    int n = 3;
    int* data = new int[n]{1, 2, 3};
    process(data, n);
    delete[] data;                 // main also cleans up — it thinks it's the owner
    data = nullptr;
}

Expected: prints 6, clean exit. Observed: prints 6, then heap corruption or a crash at exit — the same box was returned twice.

Reflection. Ownership isn’t a mood — it’s a written contract with one name on it. The const on a parameter is that contract, enforced.

D10 — The silent orphan (ownership handoff dropped)

int* loadValues(int n) {
    int* data = new int[n];
    for (int i = 0; i < n; i = i + 1) data[i] = i * 10;
    return data;                   // hands the handle AND the ownership up
}

int main() {
    loadValues(5);                 // "just load them in" — the return is discarded
    std::cout << "loaded\n";
}

Expected (by the author): values loaded. Observed: prints “loaded”; five heap boxes are leaked — allocated, returned to nobody, unreturnable.

int* data = loadValues(5);   // catch the handle — accept ownership
// ... use ...
delete[] data;
data = nullptr;

Reflection. An ownership handoff requires a receiver. Discarding a returned heap handle is dropping a live wire — catch it, or don’t generate it.

Fix-list summary