Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!cmcl2!adm!smoke!gwyn From: gwyn@smoke.BRL.MIL (Doug Gwyn ) Newsgroups: comp.lang.c Subject: Re: retiring gets(3) Message-ID: <8988@smoke.BRL.MIL> Date: 27 Nov 88 12:44:54 GMT References: <1988Nov8.054845.23998@utstat.uucp> <22402@watmath.waterloo.edu> <1988Nov27.005945.29173@utzoo.uucp> Reply-To: gwyn@brl.arpa (Doug Gwyn (VLD/VMB) ) Organization: Ballistic Research Lab (BRL), APG, MD. Lines: 57 In article <1988Nov27.005945.29173@utzoo.uucp> henry@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.