char *gets(char *s);

A C function that reads a line from stdin, and places it to string given as an argument. It also returns the string.

This function looks temptingly easy to use and cool, but it doesn't do any array bounds checking. Thus, you should not use this function! If someone inputs a string that's longer than the allocated array, in best case you get segmentation fault, in worst case you clobber your own variables with data (see buffer overflow).

This function can be easily replaced with fgets(), though.

Oh yeah, for the newbies out there: If you're looking for a good C book, browse through what your bookstore has. If the C book instructs how to use gets() and doesn't tell it's dangerous, get some other book. Good books tell why you shouldn't use it. As said, this function is not for anyone.

A better (but slower) way to get the desired result of gets() without causing buffer overflows is to use dynamic allocation like this:

char *s = NULL;
size_t len = 0;
int c;

while( (c=getchar()) != EOF && c != '\n' ) {
	s = realloc( s, ++len );
	s[len-1] = c;
s = realloc( s, len+1 );
s[len] = 0;
free( s );

(see also: malloc abuse)

gets is unquestionably the worst function in the Standard C Library. It is so unutterably bad that increasing numbers of compilers and linkers have begun issuing sternly-worded warning messages whenever a program calls it at all. (The compilers and linkers couldn't get away with this if the function had any redeeming qualities whatsoever.)

gets is responsible for a great number of the buffer overrun hacks out there. If you use gets in a program, and if the program ever actually gets used for anything, some 16 year old script kiddie will figure out a way to exploit the hole and subvert the program into doing something drastically unintended. (Some of you are saying, "No, no, script kiddies are the ones who don't know anything about programming and can only make use of exploits generated by others", but my point is that exploiting a buffer overrun is, to judge from the number of new exploits being reported every day, evidently such a well-understood, textbook problem by now that even a script kiddie can do it.)

gets. Just Say No.

BUGS: Never use gets().
--Linux man page on gets, section 3

gets was the original and simplest possible way to read a string from any input stream until a newline symbol is reached. gets' sole parameter is a char*, a pointer to the head of the array of char into which the string should be read.

gets is most notable for the parameter it does not have. gets has no "maximum read limit", nor does it have any way of figuring out how large your input array is. Therefore, gets will cheerfully run off the end of your array, into whatever memory happens to follow it, should it see input larger than the amount of memory allocated.

The most benign possible result of such a bug, known as a buffer overrun, is a quick and clean death by segmentation fault. Unfortunately, many incompetent programmers would generally simply increase the size of the array in this case, rather than actually fix the problem by using some other input system call. A segmentation fault is a clean crash of the program, and the kindest possible result. What is much more popular, especially among script kiddies, is to use the buffer overrun as an exploit into the program, to make it do things it was never intended to do. Raw machine code can be entered into the string, and careful placement of values can overwrite a return address, causing the instruction pointer to jump onto the stack, where the malicious code has been placed. The program will then execute whatever instructions it has been given, which are frequently detrimental to the health of the computer. An especially careful cracker will end the code with commands to return the program to its normal flow, none the wiser for its catastrophic error.

Use of gets, therefore, is like standing up and waving a very large sign labeled "PLEASE HACK ME". No program that uses gets can be made to be secure or stable, as there is no way to use gets and avoid the risk of a buffer overrun.

Uses of gets or similar input functions that do not check bounds are very popular causes of disastrous security holes in professional software.

Log in or register to write something here or to contact authors.