Challenge 3: Why sizeof(arr)/sizeof(arr[0]) Breaks Once Passed to a Function — Possible Solution
====================================================================

In the function where an array is actually DECLARED (e.g. main, in the
chapter's own example), the identifier `arr` genuinely refers to the
whole array object -- the compiler knows its complete type, including
its size, at compile time. `sizeof(arr)` there correctly returns the
array's total byte size (element count times element size), so dividing
by `sizeof(arr[0])` correctly yields the number of elements.

Once that same array is PASSED to another function, per the chapter's
"Array-to-Pointer Decay" section, what actually arrives as the
parameter is not the array itself -- it's a pointer to the array's
first element. Inside that receiving function, the parameter's type is
genuinely a pointer type (e.g. `int *`), not an array type, even if
it's still written with array-style syntax like `int arr[]` in the
function signature (which the compiler silently treats as `int *arr`
anyway). `sizeof(arr)` computed there returns the size of a POINTER
(commonly 8 bytes on a 64-bit system), completely unrelated to how many
elements the original array actually had -- dividing by
`sizeof(arr[0])` then produces a nonsensical, wrong element count
(e.g. 8 / 4 = 2, regardless of the array's real size).

The fix, as the chapter's warn-box states: compute the element count
once, in the scope where the array was actually declared, and pass it
into any function that needs it as a separate explicit parameter --
never try to recompute it from inside a function that only received a
decayed pointer.

WHY THIS WORKS AS AN ANSWER
------------------------------
This explains the mechanism precisely: sizeof works correctly on a
genuine array type, but decay silently changes the parameter's real
type to a pointer, so sizeof there measures the pointer instead --
naming the actual type-level cause rather than just stating "it breaks
inside functions" as an unexplained fact.