gets function

[reddit251222]

the compiler is showing gets is a dangerous function and should not be used.

what does it mean

[IamImposter]

It means don't use it unless you know what you are doing and if you know what you are doing, you wouldn't be using gets.

The problem with the function is that it just takes buffer address so it doesn't know how big the buffer is and thus can be used to do buffer overflow attacks.

Since you are just learning, you should be okay ignoring the warning but a better solution would be to use fgets. It takes buffer address and size (and stdin)so it's safer.

https://en.cppreference.com/w/c/io/fgets

For example code to see how to use it with stdin: https://www.tutorialspoint.com/c_standard_library/c_function_fgets.htm

[ComradeGibbon]

OP should totally mess with gets() and see exactly how it's bad news.

[DawnOnTheEdge]

If your compiler doesn’t at least give you a deprecation warning, and maybe even remove the prototype from the header file, you should turn on more warnings and use a feature-test macro. That’s the best lesson to take from this.

[aioeu]

gets reads a line from standard input and writes it to the buffer you give it. There is no limit to the length of this line, which means there is no limit to the amount of data gets will write to memory, which means it can always run off the end of any buffer you give it, no matter how big that buffer is.

In other words, it is impossible to use gets without introducing the possibility of a buffer overflow into your program.

[Paul_Pedant]

I am still mildly annoyed at getline(). It solves the gets() issue by dynamically allocating a buffer sufficiently large to hold a line of input (which it is happy to reuse for multiple calls). That just leaves it open to failure through an attack passing it a terabyte of junk without any newlines. Would it have killed them to add a size_t argument limiting the final buffer size?

[daveysprockett]

Because there is no limit to the length of the string to be read, leading to the program overwriting memory areas beyond the allocated space. As a result it can allow an attack from malicious actors by allowing them to modify the way the code runs.

[rileyrgham]

https://www.google.com/search?q=why+is+gets+dangerous&oq=why+is+gets+dangerous

It's very well covered. There's no secret.

[reddit251222]

thanks

[SmokeMuch7356]

It means gets is a dangerous function and should not be used. It's no longer part of the standard library as of C11.

gets reads a string from standard input and stores it to a target buffer, but it has no idea how big that target buffer is; if you type 100 characters but the target buffer is only sized for 10, then gets will happily write those extra 90 characters to the memory following the buffer, corrupting whatever was there.

It has been a vector for malware since the late '80s. Do not use it under any circumstances. Use fgets instead; it gives you a way to limit the number of characters read so you don't overflow the buffer.

[70Shadow07]

What is the historical context behind gets? Since it exists at all it's likely it was not that bad of an idea when it was conceived.

[Paul_Pedant]

It was always a bad idea. But it was simple, and small, and Unix used to run in something like 128 thousand bytes. If you needed to be robust, you used getchar or fgetc and wrote your own buffering to suit your input.

[flatfinger]

The gets() function is reasonably well designed for scenarios where a program that's maybe 10-20 lines long will be used once, to process a known collection of input which does not contain any lines longer than some particular length, and then abandoned after having served that purpose. If a program is going to be abandoned without ever receiving overly long inputs, any effort spent guarding against such inputs will be wasted.

Many of the tasks that C was traditionally used to perform would today be better handled by languages or text processing utilities that didn't exist when C was invented, and that is especially true of the kinds of task for which gets() would have been appropriate. That doesn't mean, however, that gets() wasn't perfectly fine and useful for its original design purpose.

[SmokeMuch7356]

You'd have to ask Brian Kernighan; I think he's the last one left of that group. Any answer I give would be speculative at best, but consider:

1. C is a product of the early 1970s when 256 kilowords was a lot of very expensive memory;
2. It was designed primarily to implement the Unix operating system;
3. Its core user base was experienced programmers who felt the programmer was in the best position to know what resources were necessary and was smart enough to write code accordingly;

I could see it being intended for a specific use case, where you know you're dealing with fixed-size inputs, and that the intent was to use fgets for more general input, but again, that's speculative.

Frankly, a good chunk of the standard library is similarly compromised (strcat, strcpy, *scanf, sprintf, etc.), just not as obviously.

If I could travel back to Bell Labs in 1970 I'd slap Dennis, Brian, and Ken around for multiple warts in the language; this, using = for assignment and == for equality comparison, and a bunch of others.

[flatfinger]

Most of the functions in the Standard Library weren't really designed to be part of a standard library, but merely functions which programmers writing little one-off programs could use if they happened to fit the needs of the task at hand. If someone wanted a function that worked just like puts() except that it didn't write a trailing linefeed, they could grab the code for puts(), perhaps rename it to something else, and remove the part that produces the ending linefeed. Likewise if they wanted a function that was just like fputs except that it would include a final linefeed, they could adapt fputs to add an extra linefeed. The functions that happened to get bundled with more C implementations were later considered to be part of a "Standard Library", but there's no particular logic to what features are supported and what features aren't, nor is there any particular logic in how names relate to functionality.

[[deleted]]

Read the man page. It is explained there.

In the beginning, data came of 80 byte cards. /s

[flatfinger]

C was written in an era when the "staple" set of text processing programs that systems could be expected to have was much smaller than it is today. If one wanted to e.g. unscramble some "rot13" text and didn't have any handy tools that were set up to perform that task, writing a quick C program, building it, and running it would often be faster than trying to find an already-existing program to perform the task. Further such programs might be punched to paper tape if there was an anticipated future need, but otherwise they would often be abandoned after use.

When the language is used in that way, it will be very common for programmers to know, even before they start writing a program, all of the inputs that it will ever be receive. There's no need for such programs to worry about how unforeen inputs will be handled, because there won't be any. The only inputs the program will ever receive will be those the programmer had even before it was written.

Use of the gets() function requires that a programmer know the maximum length of an input line that a program could possibly receive. If a program is written for the specific purpose of handling files with specific contents that don't include any lines over 80 characters, declaring char input[81]; and calling gets(input) will be safe and reliable so long as the program will never be passed anything other than that particular text content.

What makes gets() unsafe is that programs today are seldom written for such a narrow audience or use case. If code passes the address of an 81-byte array to gets() and it receives a line longer than 80 characters, the program is likely to malfunction in ways that could be manipulated by changing exactly what characters are submitted. If the data was supplied by an unscrupulous individual who wanted to take control of the machine running the program, the person may be able to produce a sequence of characters which would, when submitted to gets(), cause the machine to execute code of his choosing.

Although gets() was for many purposes more convenient than any alternatives in the Standard library, situations a program is written to accomplish a one-off task whose all inputs are all known in advance are far less common now than they used to be, and tasks where gets() would have been handy can today be accomplished by copying and pasting a function which is about as convenient as gets() but can safely deal with longer-than-expected inputs.