I understand why C developers don't use gets, since there are vulnerabilities that can be exploited with a buffer overflow attack, but why even have this function if it is safer to use fgets(). I suppose the question that I am asking is, are there any implications of gets() that are safe from a security standpoint?
gets
was invented in the early days of the C language, about 50 years ago, before people had thought of the concept of buffer overflow attacks and when it was assumed that users of your program would be friendly. Obviously times have changed, and in retrospect its design was a mistake. It cannot be used safely and therefore should not be used at all, and current versions of the C language standard have actually removed it. See Why is the gets function so dangerous that it should not be used?
As to why it existed in the first place, most of the stdio functions have specialized versions that operate on stdin/stdout instead of on an arbitrary stream. For instance, there is fprintf
which prints to an arbitrary stream, and printf
which assumes stdout
. It's Likewise there is fscanf/scanf
, getc/getchar
, and so on. It's mainly for convenience, so that you can save the trouble of typing stdout
everywhere.
For line-based I/O, there was fputs/fgets
for arbitrary streams, and puts/gets
for stdout/stdin. Note that puts/gets
had the special feature that they would automatically append/strip a newline character, so gets(buf)
is not exactly equivalent to fgets(stdin, buf, INT_MAX)
.
It's not entirely clear why they decided that fgets
should take a size parameter but gets
should not. There may have been an implicit assumption that stdin was more likely to be "nice" input, like terminal input or text files with reasonable line length, whereas an arbitrary file opened with fopen
might be more likely to need to handle extremely long lines and such. There are certainly many such aspects of the original C language that, again with the benefit of hindsight, were not well thought out.