Path: utzoo!utgpu!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!mit-eddie!bloom-beacon!athena.mit.edu!scs
From: scs@athena.mit.edu (Steve Summit)
Newsgroups: comp.lang.c
Subject: Re: retiring gets(3)
Message-ID: <7963@bloom-beacon.MIT.EDU>
Date: 14 Nov 88 04:06:01 GMT
References: <1988Nov8.054845.23998@utstat.uucp>
Sender: daemon@bloom-beacon.MIT.EDU
Reply-To: scs@adam.pika.mit.edu (Steve Summit)
Lines: 57

In article <1988Nov8.054845.23998@utstat.uucp> geoff@utstat.uucp (Geoff Collyer) writes:
>...gets is a bug waiting to happen and should be stamped out.

Getting rid of gets is an excellent idea.  I'm all for backwards
compatibility and not breaking existing code, but it's got to be
conscientiously written existing code, and to my way of thinking
no reasonable program should ever have been using gets.
(Apologies and condolences to those of you who do, and to the
original implementor.)

As an interim measure, why not recode gets with an implicit
maximum buffer size of, say, 512?  That is, implement it as if by

	char *gets(buf)
	char *buf;
	{
	return fgets(buf, 512, stdin);
	}

except with the requisite newline-stripping code added.  I doubt
this would break many programs, particularly since 512 is a
common buffer size anyway.  Programs that use bigger buffers will
just have to use fgets, if they don't already.

After we get rid of gets, we should get rid of calloc(n, size),
which doesn't really do anything for you that malloc(n * size)
doesn't do.  (This is not a security hole, just a quality-of-life
issue.)  calloc's only claim to fame is specious; its zero fill
property is misunderstood by many programmers and is sufficiently
useless that it can easily be replaced by bzero and/or memset for
those few instances that truly require filling with bytes of zero.
(Recall that such a zero fill does not necessarily result in NULL
pointers or 0.0 floating-point values, in the common case where
arrays or structures are being allocated.)

Finally, I'd not mourn the passing of scanf -- not just %s, but
all of it.  It just doesn't work robustly enough for its common
usage: interactive user input.  (For example, scanf("%d %d") gives
you no way of prodding the user if he only types one number;
newlines are acceptable whitespace, so the user can keep banging
the return key and getting nowhere because scanf hasn't returned
and your program can't say "please type two numbers" even if it
wants to.  A related case is scanf("%s") to read command lines:
you'd like to print another prompt if the user hits return
without typing a command, but you can't, again because scanf
doesn't return.)  sscanf can remain for picking apart strings
(perhaps read with fgets) while leaving the calling program in
control for error handling, and fscanf can remain for reading
carefully formatted data from files.

(I'm not seriously suggesting getting rid of scanf; I know how
many programs use it.  To my mind, however, there are no good
uses of scanf, but as long as it exists, people are going to keep
using it, because it is extremely convenient.)

                                            Steve Summit
                                            scs@adam.pika.mit.edu