retiring gets(3)

[Doug Gwyn]

In article <1988Nov27.005945.29173 at utzoo.uucp> henry at utzoo.uucp (Henry Spencer) writes:
>It is not necessary for a vendor to give up validation-suite compliance for
>the sake of discouraging use of gets().  How a compiler is invoked is
>compiler-specific in any case; putting gets() in a separate library and
>requiring that it be explicitly included (e.g. with "-lunsafe") retains
>compliance (and the ability to compile broken old programs) while still
>pushing in the right direction.

This is dumb, dumb, dumb.  Now you want C vendors to have to support
multiple levels of compilation, one which is harder to invoke for the
standard C environment and one that is just like it except it's missing
gets() from the C library.  This is NOT a "push in the right direction";
it adds complexity merely because some people hate a particular function.
I happen to dislike several library functions for reasons similar to
those put forth againt gets(); should vendors also segregate those out
into a -lgwyn_disapproved library?  Why would that be any more absurd
than your suggestion?

Might I suggest that you simply add to whatever code-quality checks you
perform something along the following lines and LEAVE C ALONE:
	grep -n '[^a-zA-Z_]gets[^a-zA-Z_]' /dev/null "$*" && \
		echo "Henry thinks you shouldn't be using gets()."
That is the right place to apply your notions of proper coding style.

It amazes me how ready people are to jump onto a totally irrelevant
bandwagon in the aftermath of the Internet virus/worm attack.  If
you really think that lack of gets() in somebody's C library would
have prevented the attack, you're quite mistaken.  A programmer who
made the mistake that allowed the virus to enter through the 4BSD
finger daemon would very likely have been equally careless with
numerous other language and operating system facilities.  In fact
there have been several such security holes discovered so far, and
the famous virus/worm exploited only a couple of them to enter
systems.  You cannot fix the security problems by removing every
function that somebody misuses from the C library; there wouldn't
be many left if you took that approach.  Learn to use what's there
wisely, and when there isn't a canned function suitable for the job
invent one (preferably nicely designed and published so it will
eventually be a candidate for addition to the standard library).

I avoid use of gets() in general-purpose input code, but I still
want it in the C library for the times when it IS appropriate and
useful.  If vendors really are so stupid as to try to make it
hard to find, they're going to have trouble convincing me that
they want to sell C implementations to me.  Of course if necessary
I would immediately cons up a public-domain implementation, add it
to the deficient libraries, and spread it around for others in the
same boat.  The net result would have been just a lot of extra
trouble to get back to the point from which we started.

To repeat my main point: gets() is NOT a problem.  Programmers who
don't think clearly enough about what they are doing ARE the problem.
You cannot solve the real problem by working on the non-problem.
It's at best a waste of time and potentially a nuisance; at worst it
draws attention away from real causes for lack of system security and
gives people a false sense of security, on the misperception that the
problem has been properly dealt with.