Challenge 3: Why gets() Was Unfixably Unsafe, and Why fgets's Extra Parameter Is the Real Fix — Possible Solution
====================================================================

gets()'s function signature took only a single parameter -- the buffer
to write into -- with NO way to tell it how large that buffer actually
was. This isn't a documentation problem or a matter of using it
carelessly; it's a fundamental gap in the function's own API design.
gets() would read characters from input and keep writing them into the
buffer for as long as input kept arriving, with absolutely no
information available to it about where the buffer's real boundary
was -- it could not have stopped at the right point even if its
internal implementation had wanted to, because the caller never told
it. Any input longer than the buffer's actual size (something entirely
under the CALLER's control -- e.g. a user typing a long line, or a
malicious input crafted specifically to be long) causes gets() to write
past the buffer's end, exactly the buffer-overflow class of bug from
Chapter 1's Chapter 6/8 material -- this time triggered by ordinary
program input, not even a coding mistake in the arithmetic sense.

No amount of "careful usage" fixes this, because the danger isn't in
how gets() is called -- it's that gets() itself has no way to receive
the one piece of information (the buffer's size) that would let it
protect against overflowing it. Even a perfectly careful, experienced
programmer calling gets() correctly according to its own documented
signature still has no way to make it safe, since the necessary
information was never part of the function's interface at all. This is
exactly why the C standard committee chose outright removal rather
than a stronger warning or deprecation notice -- there was no way to
use it safely, full stop.

fgets's extra size_t parameter is what actually fixes this: the caller
explicitly tells fgets the buffer's real size, and fgets is
GUARANTEED, by its own specification, to never write more bytes than
that size allows, stopping (and still null-terminating what it did
read) if the line is longer than the buffer can hold. The fix isn't
"be more careful" -- it's giving the function the one piece of
information it structurally needed to enforce a bound at all.

WHY THIS WORKS AS AN ANSWER
------------------------------
This identifies the SPECIFIC missing piece of information (buffer
size) that made gets() structurally, not just practically, unsafe --
explaining why no amount of careful calling could fix it -- and names
exactly what fgets's extra parameter supplies that resolves the actual
root cause, rather than treating "fgets is safer" as an unexplained
fact.