Challenge 1: A Deliberate Leak, Caught by valgrind — Possible Solution
====================================================================

#include <stdlib.h>

int main() {
    int *leaked = malloc(100 * sizeof(int));
    // deliberately no free(leaked) here
    return 0;
}

Compile and run under valgrind:

    $ gcc -g leak.c -o leak
    $ valgrind --leak-check=full ./leak

Representative leak summary output:

    ==12345== HEAP SUMMARY:
    ==12345==     in use at exit: 400 bytes in 1 blocks
    ==12345==   total heap usage: 1 allocs, 0 frees, 400 bytes allocated
    ==12345==
    ==12345== 400 bytes in 1 blocks are definitely lost in loss record 1 of 1
    ==12345==    at 0x...: malloc (in /usr/lib/valgrind/vgpreload_memcheck...)
    ==12345==    by 0x...: main (leak.c:4)
    ==12345==
    ==12345== LEAK SUMMARY:
    ==12345==    definitely lost: 400 bytes in 1 blocks

WHY THIS WORKS AS AN ANSWER
------------------------------
valgrind correctly identifies exactly 400 bytes (100 ints * 4 bytes)
as "definitely lost," and its stack trace points directly at line 4 --
the malloc call itself -- exactly matching the chapter's own claim
that valgrind reports leaks with a stack trace showing where the bad
allocation occurred, with no source-code changes or recompilation
needed to enable this detection.