retiring gets(3)

Doug Gwyn gwyn at smoke.BRL.MIL
Wed Nov 16 06:58:40 AEST 1988


In article <660023 at hpclscu.HP.COM> shankar at hpclscu.HP.COM (Shankar Unni) writes:
>Or do you "know" that your buffer is large enough?

Sometimes one does know exactly this.

Of course you don't know it for a general-purpose utility whose stdin
can be directed from random places.  So you don't use gets() then.

>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.

The potential for abuse of gets() was quite well known before the virus
attack.  For instance, I don't think anyone on X3J11 was unaware of it.
I'm pretty sure this has been discussed in comp.lang.c (INFO-C) more
than once before.

To take just two of the standard C texts:

Harbison & Steele, "C: A Reference Manual":
	The use of gets can be dangerous because it is always possible
	for the input length to exceed the storage available in the
	character array.

Plum, "Reliable Data Structures in C":
	Since it provides no means of specifying the size of the
	receiving string, it can seldom be used in reliable programs.
	Furthermore, it gives no convenient way to tell whether a
	newline was present in the input.  The fgets function is more
	reliable, but oftentimes awkward to use.

>From the Rationale for Draft Proposed American National Standard for
Information Systems -- Programming Language C:
	4.9.7.2  The fgets function
	This function subsumes gets, which has no limit to prevent
	storage overwrite on arbitrary input (see section 4.9.7.7).

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

I will complain if you try to enforce your notions of proper style on me,
or try to protect me from myself.



More information about the Comp.lang.c mailing list