I agree that gets() must be gotten rid of. Unless you give it an infinitely large buffer, it's always possible for the user to enter a line longer than the buffer.
Besides, is this:
really that much harder to type than this:Code:fgets(buffer, sizeof(buffer), stdin)
?Code:gets(buffer)
Originally Posted by Bayint Naung
Linux rules!
If you used Linux, you wouldn't need to restart all the time!
Last edited by MTK; 06-11-2010 at 06:32 PM.
But, but...then you have to remove the newline if it's there! And if it's not there, well then, now you have to copy what you've got somewhere else and read again! That's CRAZY talk!
I'm personally in favour of teachers discouraging use of gets().
The point of teaching a skill is to give the student enough knowledge that they can do something practically, without running too much risk of getting in trouble or causing harm.
With most scientific or engineering fields, the teaching is initially based on a small set of tools and techniques. Those tools and techniques may have limits, but they can be well understood, and the student can progress to more advanced tools or techniques once s/he knows enough to use the basic tools safely and has learnt enough discipline that they will not be inherently dangerous with an advanced tool.
A new chemistry student is not just pushed with an oxy-acetelene kit into a room with a swimming pool full of nitric acid and told to do experiments. He or she is taught some basic theory first, taken carefully through the use of lab basic equipment (beakers, bunsen burners, fume cupboards) and initially exposed to chemicals that are not harmless, then small amounts on more dangerous chemicals (sodium, magnesium, etc). As their skills build up, they are taught and allowed to do more advanced - and potentially dangerous - experiments.
Contrast this with teaching of computer programming. Students are often armed with potentially dangerous tools, told little about their dangers, and encouraged to experiment with them. Now, OK, they are not expected to write software to control a pacemaker on their first day, but the techniques or functions they are taught to use are often dangerous and actively discouraged in any professional setting - eventually they'll have to learn safer alternatives. gets() is a prime example of such a function.
I'm all for advanced students and practitioners having access to potentially dangerous tools. There is nothing worse than coddling a talented, knowledgeable, professional. However, I do not support giving those tools to beginners who don't understand them. One characteristic of beginners - particularly those who have interest or potential to eventually become great practitioners - is that they experiment and push the boundaries. If the tool they are given is inherently unsafe, they will experiment with it, and eventually use it in an unsafe manner without guidance, without any knowledge of what they are doing wrong, and get in trouble. The only way to mitigate those risks is to avoid giving them those dangerous tools before they are ready for them.
Last edited by grumpy; 06-11-2010 at 07:16 PM.
This whole conversation reminds me of this quote:
And that's why I think that things like memcpy, etc should NOT be removed. Unlike gets(), they CAN be safe if used right.
I don't think that Elysia is calling for a removal of any of the functions (except maybe gets), but an addition of some functions that are to be safer. Anyway, since we are talking about adding and removing functions from the standard, why the heck don't we see something like Gnu getline added to the standard?
Well, that's a good question, but I notice that many standard things do not necessarily rely on malloc like GNU getline does. To the end of letting people use whatever allocator libraries they really need to use, which has its own auspices. There's stuff like fopen that could obviously be implemented with other parts of the standard but that is not the point.
Last edited by whiteflags; 06-11-2010 at 08:00 PM.
Successful Troll was successful.
Quzah.
Hope is the first step on the road to disappointment.
memcpy is not safe. An additional parameter of how much to copy isn't safe.
What if you're copying X bytes of buffer Y into offset A in buffer B?
Then sizeof(dst) will give you a buffer overrun. You have to calculate the correct amount of bytes to copy, and there's the problem. You will screw that up one time or another.
Not removal. Addition.
With memcpy(), you can specify how many bytes to copy. Programmer can make sure there's no overflow. with gets(), it's not.
It's programmers' responsibility to check there's enough space in destination.
Last edited by Bayint Naung; 06-12-2010 at 03:56 AM.
I disagree, because like you, I disagree with the notion that "we should ban C, probably C++ and many other languages because they're unsafe". As such, I think that a more useful notion of safety should regard memcpy as safe, since it is safe when used correctly, which can be done in conjunction with better programming practices.
The problem is that programmers make mistakes. As such, this calls for practices such as automated testing, code review and pair programming.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
If you had been following the debate, you would know that this is the problem. We make mistakes.
However, a computer is deterministic. Therefore, once you create security checks that works, they will always work. No more buffer overruns.
Still, if there is a way to make it safer, then it's a win situation.
How many times have people here messed up the size parameter to any function like this? Oh, sure, we do it all the time. We fix it after some debugging.
Now that is dangerous.
Absolutely. But where is the harm in adding an extra security layer to catch more bugs before they propagate? The earlier a bug is caught in the development process, the better. For both the company and the end users.The problem is that programmers make mistakes. As such, this calls for practices such as automated testing, code review and pair programming.
Indeed, but the problem with Microsoft's additions is that "the secure functions do not prevent or correct security errors; rather, they catch errors when they occur". We should catch the errors before they occur.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
Yes, that's true. That would be the best thing.
But we also need some security, some kind of post-immunization that minimizes the damage that should occur in the field in form of uncaught security bugs.
Microsoft's additions are not the best. But they do aid in catching some bugs. I'd rather see functions fail instead of throwing assertions too, though.
And more checks wouldn't be a bad idea. If such a thing were possible.
One little project I did involved a lot of dealing with allocated memory and it tried to write to places it wasn't supposed to all the time.
The worst that happened was just a little message in the terminal saying "Segmentation Fault" and the program quitting, no harm done.
That just shows how naive you are about security.
Do you want your program to crash on users?
Furthermore, how about those bugs that doesn't cause a crash? The invisible ones that leaves your computer wide open to hacker attacks?
