Thread: gets() not so bad

Originally Posted by Elysia

...And one day you'll shoot yourself in the foot because you didn't think right. You introduced a bug. The bug didn't crash the program and you got a buffer overrun. Yay.
...Of course, this could have been prevented in the first place had you used safety checks.

Can happen, but:

1) I use a memchecker.
2) I'm very aware of the issue, so I'm used to dealing with it. If you want some tips just ask!

Analogy: If no one ever takes the training wheels off your bike, it will be hard for you to ride around without them.

Does that mean it is oh so hard for people to ride around with no training wheels?!?? Hmmm...

The keyword here is: can.
Maybe you forgot to run your memchecker one day. Maybe it's part of some rarely executed code so your memchecker missed it.
The possibilities are endless.

Learning to program safely is no substitute for security checks. They can augment them and increase security, but removing the security checks will hurt security.
And besides us veterans, there are newbies. They constantly make mistakes. Security checks are vital for these people.

Originally Posted by Elysia

The possibilities are endless.

Evidently

Bug are made for fixin'. Or else this is why people should not write code for computers.

Now that would be sensible.
Computers building computers and computers writing computer software

Originally Posted by Elysia

Now that would be sensible.
Computers building computers and computers writing computer software

This could lead to a personal existential crisis if drinking beer full time does not prove fulfilling enough. Also I don't have very many uses for computers beyond programming them

Oh and keeping all my .mp3's in order.

Of course there's such a thing as too much, but for buffer overruns, I don't believe so.
Sure, if we would want to foolproof as much as possible, we should ban C, probably C++ and many other languages because they're unsafe. But I don't think we should go to such extremes.

This is all about statistics. In this case, gets has such a bad statistic that they ban it. But strcpy, memcpy, whatever have pretty bad buffer overrun statistics too, I would bet. Even though they may be safe to use under correct circumstances, they prove to be security risks since it's so easy to use them incorrectly.

I would like to label users as stupid, too, but there must be an effort from both universities and the language. By adding (and not removing the old ones) safe string handling functions, and universities teaching these safer ones, we get safer code. Win-win.

It may be true that you can't bulletproof everything, however gets is not one of these things. Given the fact that we have fgets, gets is not only bad it's redundant. I don't think that if they banned gets() there would be a lot of tears over it.

Originally Posted by nonoob

Can the regulars here stop deriding & insulting professors who teach students to use gets()?

I use this function all the time. It's perfectly wonderful. Every program is likely to have way more places in them where things can blow up. The last thing a student of C needs to worry about is some orchestrated attack by someone who would exploit buffer overruns... Such users are not likely the audience for assignment project code.

Not every piece of code needs to be criminal-hacker proof. Just make sure the buffer is reasonably large. Say, a reusable buffer of 500 bytes for simple inputs.

Do you enjoy it when an attacker installs adware on your machine, or a keylogger to capture your passwords, or a when your harddrive is wiped clean unexpectedly? Do you like that fact that Windows updates are frequently required to be downloaded to your machine and your PC restarted?
We don't!
Lack of teaching security as part of programming is where the need for things like Windows updates has come from. When computers first came out whey were so large and expensive and hardly anybody knew how to program them. Their RAM was measured in KB etc ctc. They didn't have networks, and there weren't people out there who could make money off spam. Back then security was not really an issue. Things moved along a bit and we got home personal computers. These still typically weren't networked and their RAM was perhaps on the order of a few MB. A few people knew how to program them, but not many people stored vast amounts of critical data on them. And still, security was barely considered. The professors you speak of probably grew up around this era.
At some point computers became common enough and networked and so easily programmable that security became a huge problem. People needed to learn that just because security had not been an issue in the past does not mean that it can be ignored now. Somewhere along the path to the modern PC you have got to realise that security needed to become a major focus, an integral part of programming itself. Those that have never been taught security as part of programming are the main problem. They continue to produce unsafe code to the detriment of the rest of us.

Your argument is not merely about gets vs fgets. You want to go back to the days where security was not an issue. You want to do as your 10-20 year old C programming books say and use the functions that they claim you should use, because they're so awesomely correct. You at best believe that one first needs to learn how to program and then maybe they can learn a little about security on the side. This simply is not sufficient today!
This needs to change and the current generation of wannabe programmers needs to learn security at every step along the way to becoming a real programmer. From the moment a new programmer first learns how to get input from the user or from a file, they need to be taught how to do it safely. Only then will we come close to having software that is seldom exploitable.

When engineers are taught how to build a bridge, they are hopefully taught how to make something that is done correctly and will hold the weight it was designed for and withstand the forces of nature that are expected in the area, and then some etc. They aren't just taught to make something that will stay upright when you take away the temporary supports. It's just not enough. You wouldn't be given rubber supports to make a bridge out of, so why should you be given gets for accepting user input when we know it's crap?!

If you don't have the time to learn how to program properly then pick another career. Perhaps become a lion-tamer, where it wont matter if you don't learn to be careful as you go.

And no, Microsoft compilers are not the only ones to emit warnings whenever gets is used.

Btw, a buffer of 500 bytes is not nearly large enough. When malicious input comes into play, it's usually way bigger than that. Oops, you're screwed.

You can't call memcpy bad without calling pointers themselves bad.
I.e. you can't avoid the problem it could cause without avoiding pointers altogether.

Originally Posted by whiteflags

Also, believe it or not, I would like a function that just copies bytes.

Who says anything about removing it? It will still be there, in one form or another.

It may be mean of me to point this out but I'm glad that one person doesn't have the choice to redact things from the standards.

That is a good thing(TM).

Reminds me of that joke... "How many Microsoft employees does it take to change a light bulb?"
"None, they just make darkness a standard."

Microsoft have the history of renaming functions if they don't want you to use them (Think POSIX). There goes some of your portability. If it's in the standard, leave it alone, but feel free to give a big fat warning if someone is using gets(). If Microsoft find memcpy() "dangerous", then my goodness, don't let them do any string processing in C.

Not to mention, the "safe" functions don't stop you from passing uninitialised pointers, or "the wrong pointers" to them.