Like Tree40Likes

strcpy get errors

This is a discussion on strcpy get errors within the C Programming forums, part of the General Programming Boards category; How would you know that "there are exactly three characters to be read from the stream before the new line ...

  1. #76
    Stoned Witch Barney McGrew's Avatar
    Join Date
    Oct 2012
    Location
    astaylea
    Posts
    420
    How would you know that "there are exactly three characters to be read from the stream before the new line character", without making the use of gets redundant?
    I suppose you could use fseek on binary streams.

    In such a case, you might win the argument on a technicality, but the win would be pointless in reality.
    Why is it pointless? It'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. It might not be useful to use gets safely, but it can certainly be done.

  2. #77
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,303
    To me, it's like saying that a gun is safe, because it can be used to turn on and off a light switch.
    Fact - Beethoven wrote his first symphony in C

  3. #78
    Stoned Witch Barney McGrew's Avatar
    Join Date
    Oct 2012
    Location
    astaylea
    Posts
    420
    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. Unlike the danger of potentially killing a human that you have with firing a gun at a light switch, the method I used has no such danger. That danger, however, is certainly present if you make various assumptions about the kind of input that passes through stdin.

  4. #79
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    Quote 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.

    Quote 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.

    Quote 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.

    Quote 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).
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  5. #80
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,303
    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.
    Fact - Beethoven wrote his first symphony in C

  6. #81
    Stoned Witch Barney McGrew's Avatar
    Join Date
    Oct 2012
    Location
    astaylea
    Posts
    420
    @laserlight:
    Checking the standard though, fseek could work on text streams too, so that is not the problem.
    Right, I was thinking about another issue that isn't really applicable here, so I decided to specify 'binary' stream without following that thought all the way through.

    Rather, it is a possible problem in practice for stdin.
    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.

    It would have been more convincing if you had say, used fseek on stdin as a working (or not working) proof of concept.
    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.

    @Click_here:
    I wasn't talking about firing it at the light switch - Just flicking the switch with it.
    The implication is that it has the potential to inflict harm, right?

  7. #82
    Fountain of knowledge.
    Join Date
    May 2006
    Posts
    794
    Quote Originally Posted by Click_here View Post
    I wasn't talking about firing it at the light switch - Just flicking the switch with it.
    And you could maybe fire it at the light bulb to switch it off.

    You would get through a lot of bulbs that way though.

  8. #83
    TEIAM - problem solved
    Join Date
    Apr 2012
    Location
    Melbourne Australia
    Posts
    1,303
    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?...
    Fact - Beethoven wrote his first symphony in C

  9. #84
    Stoned Witch Barney McGrew's Avatar
    Join Date
    Oct 2012
    Location
    astaylea
    Posts
    420
    but I have created a stupid, redundant way of using it to prove that it is safe.
    I'm not saying it's safe or unsafe, I'm saying it can be used safely and unsafely in different situations. Thanks for attempting to butcher my argument.

  10. #85
    Registered User
    Join Date
    Jun 2005
    Posts
    5,843
    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.
    Right 98% of the time, and don't care about the other 3%.

  11. #86
    Stoned Witch Barney McGrew's Avatar
    Join Date
    Oct 2012
    Location
    astaylea
    Posts
    420
    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.
    Last edited by Barney McGrew; 01-17-2013 at 01:36 AM.

  12. #87
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    Quote 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.

    Quote 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.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

  13. #88
    Stoned Witch Barney McGrew's Avatar
    Join Date
    Oct 2012
    Location
    astaylea
    Posts
    420
    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
    I've already provided such an example. Here's one that you can interpret by simply pasting the code:

    Code:
    #include <stdio.h>
    int main(void) { char c; if (ungetc('\n', stdin) != EOF) gets(&c); }
    Now make it crash.

  14. #89
    Registered User
    Join Date
    Nov 2012
    Posts
    979
    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.

  15. #90
    C++ Witch laserlight's Avatar
    Join Date
    Oct 2003
    Location
    Singapore
    Posts
    20,968
    Quote 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.

    Quote 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".
    Salem likes this.
    C + C++ Compiler: MinGW port of GCC
    Version Control System: Bazaar

    Look up a C++ Reference and learn How To Ask Questions The Smart Way

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Help using strcpy
    By laxkrzy in forum C Programming
    Replies: 1
    Last Post: 11-15-2010, 10:09 PM
  2. Replies: 1
    Last Post: 06-19-2010, 07:42 AM
  3. What's up with this strcpy?
    By fanoliv in forum C Programming
    Replies: 7
    Last Post: 06-19-2006, 05:24 PM
  4. strcpy
    By Tibo in forum C Programming
    Replies: 2
    Last Post: 03-27-2003, 06:02 AM
  5. strcpy
    By Unregistered in forum C++ Programming
    Replies: 6
    Last Post: 08-01-2002, 01:39 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21