Thread: strcpy get errors

To me, it's like saying that a gun is safe, because it can be used to turn on and off a light switch.

Originally Posted by Barney McGrew

I suppose you could use fseek on binary streams.

Maybe, but I don't think that fseek is guaranteed to work for stdin. Checking the standard though, fseek could work on text streams too, so that is not the problem. Rather, it is a possible problem in practice for stdin.

Originally Posted by Barney McGrew

Why is it pointless?

Because your example just does something that can be done by direct assignment. It would have been more convincing if you had say, used fseek on stdin as a working (or not working) proof of concept.

Originally Posted by Barney McGrew

t's just more accurate to talk about functions being used in unsafe ways than it is to talk about functions being inherently unsafe. Many try to make that claim about strcpy and memcpy (eg. Microsoft To Banish Memcpy() - Slashdot), but obviously the issue is that people are just using those functions in unsafe ways, since they can definitely be used safely.

Agreed, hence my observation that scanf with %s can be used safely, even if some code in this thread didn't. The same definitely goes for strcpy and memcpy.

Originally Posted by Barney McGrew

Even if undefined behaviour kills humans on various implementations of C, none are going to die if you can guarantee that there are fewer characters and a new line character to be read from stdin than you have accessible through the pointer you pass to gets.

Agreed, because by definition you would not be vulnerable to a buffer overflow if that was done, if it can be done (reliably).

Unlike the danger of potentially killing a human that you have with firing a gun at a light switch

I wasn't talking about firing it at the light switch - Just flicking the switch with it.

No

My point is that a gun is always dangerous and it is not designed to flick a light switch on and off - It is a job that you would use your hand for, but I have created a stupid, redundant way of using it to prove that it is safe.

Sound formiliar?...

You were actually saying your approach is safe.

Your argument is specious anyway. But, apparently, you expect others to accept it, even though you won't accept an equally silly argument.

Your argument is specious anyway.

How is it specious? Here are the claims I've made:

• gets can be used safely.
• gets can be used unsafely.

Since I've already given you an example where the first point is true, and the second point is widely accepted, how is the argument false? If you can't somehow argue that gets cannot possibly be used safely, then you have no possible way to disagree with my core claims.

Then I went on to suggest that it's stupid to say that gets is inherently unsafe (or even safe, for that matter) for the above two reasons, and that it should depend ENTIRELY on how it's used. Now, I can see how your interpretation might possibly differ based on this, so if you want an argument and can't prove that first claim to be false, then I suggest basing it on this point.

even though you won't accept an equally silly argument.

Dunno what you're referring to. Click_here tried to say I was somehow suggesting that gets is safe because it can be used safely, and then provided an analogy to demonstrate why it isn't the case. Why on earth would I accept his counter-argument for an argument I never made?

edit:

You were actually saying your approach is safe.

Yes, I said my *approach* is safe, but I didn't say gets was safe. Click_here's analogy relates a gun with gets.

Originally Posted by Barney McGrew

It tends to fail when stdin is connected to a device like a terminal or a pipe. However, it tells you that by returning a non-zero value, which should certainly be checked for and handled if your program depends on the success of the reposition.

Unfortunately, when that happens, to stick to using gets safely, unless you have some other solution besides your proposed fseek, you would have to say, fallback to using fgets or the POSIX standard getline. Thus, it would be far simpler to just use fgets or getline to begin with.

Originally Posted by Barney McGrew

My motive is to encourage people to think about the issue in a different way rather than to promote the use of gets; to look at how gets is used and take issue with that rather than the fact that it is simply used.

I see. Frankly, I have never considered that there was a safe way to use gets. fseek never crossed my mind precisely because I have not used it with stdin in practice, probably because it has failed on me. So, thanks for your encouragement, but it really makes no difference: unless you are going to properly present a way to use gets safely rather than merely claiming that it can be used safely and then refusing to actually write code as a proof of concept with the excuse that you do not want to promote the use of gets, encouraging people to think about such a way is just a waste of time, unlike say, the same exercise with strcpy. I am certainly not going to take issue with the way that gets is used when I am not convinced that I know the "right way" to use gets. Rather, I will continue to take issue with the fact that gets is used.

Can we make an example that actually does something useful? Like grumpy said earlier, why would one actually use this and not just write c='\n', for example? Also if EOF occurs, then the contents of c is undefined.

I think we're missing the point here. Functions make assumptions, and those assumptions are the cause of lack of safety. For example strcpy(dest, src) makes the assumptions:
1. src is terminated by '\0'
2. dest is large enough to hold strlen(src)+1

If either of these assumptions is not true, then the result is undefined. This is UNSAFE, yet it is fairly reasonable to imagine a situation where you can guarantee both assumptions. Now let's look at gets(str). It assums:
1. str is large enough to hold all characters that come from standard input until a '\n' occurs

So the assumption is the problem. In what situation can you reasonably ensure this assumption? Make a trivial program similar to `yes' that spits out 'y' characters (without the newline), and then pipe it into a program which uses gets. That is the problem.

Originally Posted by Barney McGrew

I've already provided such an example. Here's one that you can interpret by simply pasting the code:

Grr... I'm talking about one to say, read some text from the user and print it back. A proof of concept that can actually be used for real.

Originally Posted by Barney McGrew

Now make it crash.

I don't need to do that when I can see that it is okay. But I can also see that it has the same net result as:

Code:

#include <stdio.h>
int main(void)
{
    char c = '\n';
}

Therefore, I do not find it admissible "to look at how gets is used and take issue with that rather than the fact that it is simply used". The fact that you bring this up again despite me noting that it is not convincing makes me feel like you're just out to win an argument on a technicality for the sake of it rather than actually to "encourage people to think about the issue in a different way".