Challenge 2: Returning a Reference to a Local Variable — Possible Solution
====================================================================

#include <iostream>

int& make_dangling() {
    int local = 42;
    return local;  // returning a reference to a local — dangerous
}

int main() {
    int &ref = make_dangling();
    std::cout << ref << std::endl;  // undefined behavior
    return 0;
}

What happens: this compiles (often with a compiler warning like
"reference to local variable 'local' returned," but it is NOT a hard
compile error), and running it produces undefined behavior -- the
program might print 42 by coincidence (if that memory hasn't been
reused yet), might print a completely different, unrelated value, or
might behave unpredictably in some other way. Nothing is guaranteed.

This is precisely c1-7's own dangling pointer scenario, just in
reference form: local's storage is a stack variable belonging to
make_dangling's own function call, and per that chapter's own rule,
that storage becomes invalid the instant the function returns. The
reference ref in main is left referring to memory that no longer
belongs to anything meaningful -- the same underlying problem as
returning &local_var from a plain C function, except here it's spelled
with reference syntax instead of an explicit pointer, and there's no
'&' at the call site to even hint that anything address-related is
going on.

WHY THIS WORKS AS AN ANSWER
------------------------------
This correctly identifies the result as undefined behavior (not a
specific guaranteed wrong value) and explicitly maps the mechanism back
onto c1-7's own dangling-pointer explanation (local's stack storage
becomes invalid on return), showing this is the same underlying bug
class wearing reference syntax rather than a new, unrelated problem.