Thread: gets() not so bad

The thing is, I wrote "can," which does not necessarily mean "will".
It's entirely plausible, though. Consider this scenario:
You have a temp file stored in some char buffer. Then you read some input from the user. You get a buffer overrun, so it overwrites the contents of the buffer to the temp file.
You close the temp file and delete it. Ah, but the contents of the path to the temp file was overwritten due to the buffer overrun. Oops.
This is the real danger. We wouldn't want this, would we?

Originally Posted by whiteflags

I don't think changing standards is the best or even preferred way to deal with this type of problem.

Changing a relevant standard, however, is an option to replace a function that has an unpreventable unsafe mode of operation (i.e. no way of using it safely) with a function that has one or more modes in which it can be used safely.

A function with no safe mode of operation is inherently dangerous - there is a risk with using it that cannot be eliminated. A function with one or more safe modes of operation can, with reasonable effort, be used safely.

Originally Posted by whiteflags

In the first place, even examples of safe functions you defend are just as much examples of the problem. Every function depends on correct arguments, memcpy and _memcpy_s included. Without compilers double checking, or ...anything, adding arguments wont make things safer if you seriously want to use that argument.

Using that of sort of logic, we wouldn't develop software at all. It is possible to find an unsafe mode of operation of almost anything: language constructs, library functions, etc.

memcpy() can be used safely, in the sense that it can be guaranteed to behave correctly if it is provided with an appropriate set of arguments. gets() cannot.

You are misunderstanding here.
These safer versions aren't meant to replace smarter programmers. They're there to complement smarter programmers, because even veteran developers make mistakes. You can't write bulletproof code. You can only reduce the risk of security vulnerabilities. And the more you reduce vulnerabilities, the better.

And I already addressed your concerns. Why are you learning programming in the first place? If it's in a university, it's usually because there's an idea behind everything! Because one day you might be writing software for something!
Besides that, there is always the risk that some malicious software just scans through the computer trying to find some vulnerable code and uses it to its advantage!
Even worse, you might one day share your code in some form or way, and other people use it without understanding its implications and you've just used gets!

You don't see people using a chainsaw, even to cut small branches, without being aware of the security implications, do you? Programming is the same. There are basic guidelines which everyone--hobby or professional!--must follow. And gets is one of them.

Maybe we should be teaching those students how to exploit buffer overruns. How to give it input that will delete folders even when there's no call to the "delete folder" function in your program's source. How to make it turn even the most inane programs into gaping security holes.
Then maybe people would complain about Vista's UAC a lot less. Maybe people would think twice about downloading that "magic" it-does-everything software. Teaching people how to exploit their systems is the best way to teach them to protect against exploits.

I really like nonoob's idea here:

It's like equipping public playgrounds with rubberized matting these days. Kids will never know there are pitfalls. Never mind instilling a better sense of balance and coordination.

And this goes beyond programming - it's infected our school system. But I'll leave that for another day in GD.

No, showing by example is definitely a good idea. Just saying "this is bad" is never a good way to teach. You have to teach people why it is that way. That is why we have proofs in our math books!

I can't believe this thread is still going on.

The problem is simple:

gets=bad, use it at your own risk.

The problem is even simpler:
gets=bad
Never use it.

Originally Posted by nonoob

When a student writes a "hello world", or some algorithm testing program, he should not be worried about a hacker installing keyloggers and exploiting buffer overruns. That's just not a realistic concern.

Agreed. However why should a student learn something that they'll have to unlearn later and learn it's safe replacement for? Why not just learn the safe method to being with? Breaking old habbits can be hard.

Same goes for quickie utilities I write for my company. Simple prompts, simple answers, file names, etc. There is never going to be an army of industrial hackers let loose on this code.

Yes but buffer overruns can happen accidentally, not just through hacking. Classic case is accepting a file path and some user trys a rather long path, or attempts to enter multiple paths separated with semicolons or whatever, hoping it will understand that. If you're lucky it simply crashes.

This will probably tick off the purists and the OP but the simple truth is this: folks who think that "using such and such dangerous routine because (pick one of "its just a throw-away project", "its just a learning project", " no one will ever use this in a dangerous manner or for a risky purpose"), simply demonstrates their lack of real-world skills and experience. The one constant is that your software will almost invariably be used in a manner that you had never envisioned. Moreover, if you get used to writing such dangerous code, sooner or later you will get hired into a company or position where it does matter and your habits will expose the company to dangers and most likely lose you your job.

The Microsoft environment has blown up a lot more frequently than my throw-away code. That tells me their good advice about avoiding risky code should be better practiced by their own staff before they preach to me. Or they should have implemented run-time array bounds checking in their compiled code even though it's beyond what pure C would let you get away with.

Operating system blowups are inexcusable. Those happen when no one is even trying to hack on purpose.

Do you really think people lose their jobs at Microsoft every time something croaks? They'd have a bunch of empty buildings by now. More like buildings with negative number of people in them.

Please don't imply I have little real-world skills and experience. I have gone so far as to grab key codes myself so that I would not need to rely on potentially flaky library code - when it mattered if the user pressed left or right shift key, and when I wanted to intercept any function-key, or ctrl-alt-delete shenanigans. But that was years ago. Current operating systems make taking control of the hardware increasingly difficult.

By Microsoft environment, you mean...?
Also, Microsoft software is buggy, not insecure. Those are two very different things. I very much doubt that they write outside array bounds.

Operating system blowups usually is because of 3rd-party code. Don't blame Microsoft; blame the developers of the software you're installing.

You have little experience, you are naive or you're just pure dumb. Anyone who says gets is good is either inexperienced, naive or just an idiot.