retiring gets(3)

Geoff Collyer geoff at utstat.uucp
Sat Nov 12 09:26:29 AEST 1988


> From: gwyn at smoke.BRL.MIL (Doug Gwyn )
> 
> gets() is deliberately required for ANSI C standard conformance because
> a LOT of existing code relies on it.

That's the whole point, Doug.  People *should* fix their existing code;
it's unsafe.

> Any vendor who omits this function
> will not be standard conforming and will not sell its compiler to those
> (expected to be MANY customers) who specify standard conformance.

Once the standards are changed, their code *will* be standard-conforming.

> Even if your philosophy is right, you should get others to go along with
> it BEFORE trying to force them to conform to it.

That's what I'm trying to do now: get people to agree, and then act on
that agreement.

> By the way, have you removed scanf() from your C library as well?  Or
> sprintf()?  Or strcpy()?  They can be misused in the same way as gets().

No, I have not; all of these functions *can* be used safely, though it
does take a little extra care.  The point is that gets() *can* *not* be
used safely; a dedicated opponent can *always* defeat a program that
reads with gets().

> I think the appropriate treatment of gets() is to omit it from the
> documentation or to document it with "Unless you have sufficient control
> over the data being read to be sure that it will not overflow the buffer,
> use fgets".

It is in general not possible to have sufficient control over the input
data.  Remember the old maxim "Never trust any input." or, as Kernighan
and Plauger put it in Elements of Programming Style, "Make sure input
cannot violate the limits of the program.".  It is *not* *possible* to
ensure that input cannot violate the limits of a program which uses
gets().  Someone can always provide input longer than the program's
gets() buffer.
-- 
Geoff Collyer	utzoo!utstat!geoff, geoff at utstat.toronto.edu



More information about the Comp.lang.c mailing list