Challenge 2: Writing Past the End of an Array Into an Adjacent Variable — Possible Solution
====================================================================

#include <stdio.h>

int main() {
    int arr[3] = {1, 2, 3};
    int sentinel = 42;

    arr[4] = 999;  // out of bounds — arr only has indices 0-2
    printf("%d\n", sentinel);

    return 0;
}

Possible output (not guaranteed -- this is undefined behavior, so the
exact result depends on the compiler, platform, and memory layout):

    999

What's happening: arr only has valid indices 0, 1, and 2 -- index 4 is
two positions past the end of its actual allocated memory. Because C
performs no bounds checking at all (per the chapter), arr[4] = 999
doesn't fail or get rejected -- it simply writes 999 to whatever memory
address happens to be 4 ints past arr's starting address. Since local
variables often end up laid out adjacently in memory, that address
may happen to be exactly where sentinel is stored, silently
overwriting its value from 42 to 999 with no error, no warning, and no
indication anything went wrong.

Why C allows this: per the chapter, an out-of-bounds array access is
undefined behavior, not a checked error -- the language simply never
verifies that an index is within range before using it, unlike Rust's
[T; N], which performs that check on every access and panics rather
than silently reading or writing the wrong memory.

WHY THIS WORKS AS AN ANSWER
------------------------------
This demonstrates the exact "silent corruption of an adjacent variable"
scenario the chapter's own example describes, correctly flags that the
specific result isn't guaranteed (since it's undefined behavior, not a
deterministic language feature), and explains the ROOT CAUSE (zero
bounds checking) rather than treating the corrupted value as a mysterious
bug.