Challenge 3: Why "It Didn't Crash" Isn't Proof of Correctness in C, But a Successful Rust Compile Is Different — Possible Solution
====================================================================

Per the chapter's own warn-box, undefined behavior in C carries NO
guarantee about what actually happens when it occurs -- not even a
guarantee of crashing. The C standard simply declines to define any
outcome at all for a use-after-free, a buffer overflow, or a
double-free; whether a given run of the program crashes, silently
corrupts unrelated data, or appears to "work" perfectly depends
entirely on incidental factors like the compiler, optimization level,
memory layout, and sheer luck about which bytes happened to be
overwritten and whether anything ever reads them. A program riddled
with real memory bugs can run correctly thousands of times in a row on
one machine and still be genuinely, seriously broken -- the absence of
an observed crash proves nothing about whether the underlying bug
exists, only that this particular run didn't happen to trigger a
visible symptom.

This reasoning does NOT apply to a Rust program that compiles
successfully, and for a fundamentally different reason: Rust's
borrow checker and ownership rules are enforced BEFORE the program
ever runs, as a precondition of compilation succeeding at all. A Rust
program that fails to compile because of a potential use-after-free,
double-free, or dangling reference simply doesn't produce an
executable in the first place -- there is no "it compiled but might
still have the bug" middle ground for this specific class of error,
the way there is with C's runtime-only detection. A successful Rust
compile is a genuine, structural GUARANTEE that this entire bug class
is absent from the program (within safe Rust) -- not merely evidence
that testing so far hasn't happened to reveal a problem, which is all
"it didn't crash" can ever honestly claim about a C program.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains precisely WHY a lack of crashes proves nothing in C
(undefined behavior carries no guaranteed symptom at all, so absence
of a crash is not evidence of absence of the bug) and precisely why a
successful Rust compile is categorically different (the check happens
BEFORE runtime, as a precondition of the executable existing, rather
than being something that might or might not manifest during any given
run).