Path: utzoo!attcan!uunet!ncrlnk!ncr-sd!hp-sdd!hplabs!hpda!hpcuhb!hpcllla!hpclisp!hpclscu!shankar
From: shankar@hpclscu.HP.COM (Shankar Unni)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <660023@hpclscu.HP.COM>
Date: 14 Nov 88 22:00:05 GMT
References: <5450@saturn.ucsc.edu>
Organization: HP NSG/ISD California Language Lab
Lines: 27

> gets() has legitimate uses.  It is in the library Base Document.
> It is widely used in existing code (sometimes safely, sometimes not).
> It stays.

Exactly how do you use gets "safely"? There is really no way to stop gets
from overwriting the end of your buffer, unless you fiddle around with the
internals of stdio. Or do you "know" that your buffer is large enough? (This
might be acceptable for a limited situation, like when you or a trusted
co-program is writing stuff that you're reading from stdin, but in a more
general case, it's impossible). 

The thing about gets is that until now, the hazards of using it have not been
adequately advertised. There is no mention in any book or reference on C
about how gets can be perverted to blow away your application. It does occur
to most C programmers ultimately that there is "something wrong" with gets
when you cannot specify the max length to read in, but the magnitude of the
problem rarely sinks in.

This is why the suggestion of moving gets() to a compatibility library
sounds so good: this gives you the opportunity of making C programmers
re-evaluate their use of gets(), and replace it with fgets() if they are
unsure of the security and integrity implications of using gets().

But then, C programmers are such a spoilt bunch (sigh!). They scream and
moan at the least little trouble they are put to :-(.
----
Shankar.