Talk:Gets

With regard to the statement that the use of gets is deprecated, in addition to the injunction on the man page "Never use gets", note that gets is cited as an example of deprecation for reasons of security in the article deprecation. Bill 01:05, 15 March 2006 (UTC)[reply]

I agree that gets should never be used, but can you point to an official standard that deprecates it? C99 doesn't. Eric119 01:36, 15 March 2006 (UTC)[reply]

It isn't deprecated in an official standard, but the term deprecated doesn't always refer to intended withdrawal from a standard. Bill 01:41, 15 March 2006 (UTC)[reply]

Okay, I'll change the article to reflect this. Eric119 01:45, 15 March 2006 (UTC)[reply]

That looks good. Bill 02:10, 15 March 2006 (UTC)[reply]

As of a recent C99 revision, the gets() function is now officially deprecated (ISO/IEC9899:TC3, 7.26.9 says "The gets function is obsolescent, and is deprecated."). Medinoc (talk) 09:38, 8 April 2008 (UTC)[reply]

No quick fix?

The critical difference between gets overflows and buffer overflows involving other standard C functions, such as scanf, is that calls to scanf can usually be corrected by changing the format specifier (e.g., changing "%s" to "%20s"). There is no such "quick fix" for gets.

Isn't replacing it with a call to fgets exactly analogous to replacing "%s" to "%20s" in a scanf call? Until somebody can show me otherwise, I've removed these sentences. - furrykef (Talk at me) 14:44, 29 June 2006 (UTC)[reply]

Actually, fgets(buffer, sizeof buffer, fp) is different from gets(buffer) in that fgets will always try to store the line-terminating newline character, whereas gets never will. So it's not a drop-in replacement. However, I don't think that fact is important enough to need an explicit mention in the article. --Quuxplusone 08:59, 4 December 2006 (UTC)[reply]

For loop style

I changed the function to use a more natural for loop style. Eric119 06:09, 4 December 2006 (UTC)[reply]

I changed the for loop to a while loop hoping to create a even more natural loop. KBayes (talk) 22:03, 21 June 2010 (UTC)[reply]

History

Can anybody drop a few lines about the history of this function? Maybe this would make it more clear why this mess was included into C89 at all... --79.245.112.107 (talk) 21:55, 30 May 2011 (UTC)[reply]

There certainly must be some interesting history, but I can't find it. The old C programming language book, from which much of the C library is derived, does not describe gets, but instead describes a much better function called getline(). Somehow this was dropped.Spitzak (talk) 18:59, 31 May 2011 (UTC)[reply]

In older Unix systems and still many today, lines in text files and on stdin, including the trailing newline, were limited to LINE_MAX (in limits.h) characters. The gets() function was a simple way to receive a line from stdin because all that was necessary was to declare a buffer of LINE_MAX characters, and it was guaranteed that the entire line will fit into the buffer, including the newline which was replaced by a null character, since it's impossible for any program to read or create lines of a greater length and still be interoperable with standard Unix utilities and C functions. You could use getchar() or fread() to exceed this limit, but then standard tools like cat, vi, or sed would be unable to work with those files properly, or would be required to treat them as "binary" files. But today, most programs and operating systems use dynamic buffers for lines, so gets() has no real limit on the size of the line, instead of the implicit limit of LINE_MAX. The getline() function malloc()s enough memory to fit any line, which would only cause the return of a NULL pointer rather than a buffer overflow in case there's not enough memory. 76.205.126.132 (talk) 21:42, 23 June 2011 (UTC)[reply]

Such a limit may be true of terminal drivers (ie when in "cooked" mode, where backspace, etc, worked). I am certain it is false for even the earliest Unix systems for files. There is no "line" data structure in Unix so there is no possible method or reason to impose such a limit, and you could construct a file with any length of "line" up to the space available on disk by doing putchar() of anything other than a newline a sufficient number of times.

However the explanation may make sense. gets() may have been considered quite safe on early Unix as it was only used for stdin. Input redirection I don't think was in the very first versions, so there was no possibility you could use it to read anything other than a terminal. I believe these very first versions also were in effect "raw" terminal mode all the time, and gets() may have run a library function that did (probably very simple) line editing and thus could easily limit the text to a fixed buffer size.

Still would be nice to find an actual source for the history. Input redirection was added very early to Unix.Spitzak (talk) 20:01, 24 June 2011 (UTC)[reply]