Thread: Strcpy function .

  1. #1
    Registered User
    Join Date
    Sep 2011
    Location
    Athens , Greece
    Posts
    357

    Strcpy function .

    Hello to all.

    According to documentation the code below produces undefined behaviour?

    Code:
    #include<stdio.h>
    #include<string.h>
    
    int main(void)
    {
    	char str1[]="Hello";
    	char str2[]="This string is bigger than str1";
    	
    	strcpy(str1,str2);
    	
    	puts(str1);
    	
    return 0;
    }
    The

    Code:
     strcpy (str1 , strcpy(str2 , "abcd");
    is recursion ?

  2. #2
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    The "documentation" is correct in your first example.

    Your second example is not recursion.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  3. #3
    Frequently Quite Prolix dwks's Avatar
    Join Date
    Apr 2005
    Location
    Canada
    Posts
    8,057
    I'm not sure what your question is. Yes, using strcpy to put too much data into an array (more data than there is space in the array) is a buffer overrun, which is undefined behaviour. Your program may crash some of the time, and certainly it's a security risk.

    The strcpy function "returns a pointer to dest", according to the documentation. So
    Code:
    strcpy(str1, strcpy(str2, "abcd"));
    would be the equivalent of
    Code:
    strcpy(str2, "abcd");
    strcpy(str1, str2);
    which is fine. It's not recursion. Recursion is where one function calls itself (directly or indirectly). strcpy() would only be recursive if it called strcpy(). Here you're just invoking strcpy() twice in succession, one after another.
    dwk

    Seek and ye shall find. quaere et invenies.

    "Simplicity does not precede complexity, but follows it." -- Alan Perlis
    "Testing can only prove the presence of bugs, not their absence." -- Edsger Dijkstra
    "The only real mistake is the one from which we learn nothing." -- John Powell


    Other boards: DaniWeb, TPS
    Unofficial Wiki FAQ: cpwiki.sf.net

    My website: http://dwks.theprogrammingsite.com/
    Projects: codeform, xuni, atlantis, nort, etc.

  4. #4
    Registered User
    Join Date
    Sep 2012
    Posts
    357
    1. Yes, it produces UB. You try to put more characters in str1 than there is space for. str1 has space for 5 characters and the zero terminator, you try to put 31 and the zero terminator in that space.

    2. No, it is not recursion.

  5. #5
    Registered User
    Join Date
    Sep 2011
    Location
    Athens , Greece
    Posts
    357
    Quote Originally Posted by dwks View Post
    I'm not sure what your question is. Yes, using strcpy to put too much data into an array (more data than there is space in the array) is a buffer overrun, which is undefined behaviour. Your program may crash some of the time, and certainly it's a security risk.

    The strcpy function "returns a pointer to dest", according to the documentation. So
    Code:
    strcpy(str1, strcpy(str2, "abcd"));
    would be the equivalent of
    Code:
    strcpy(str2, "abcd");
    strcpy(str1, str2);
    which is fine. It's not recursion. Recursion is where one function calls itself (directly or indirectly). strcpy() would only be recursive if it called strcpy(). Here you're just invoking strcpy() twice in succession, one after another.
    Yes you are right about strcpy ... if we put this statement ->

    Code:
    strcpy(str1, strcpy(str2, "abcd"));
    into main() .... main is the caller of strcpy. Not strcpy itself . We simply call strcpy twice in a complex expression.
    Recursion is when the caller calls itself ....

    p.s I would like compiler to inform me that strcpy is dangerous..... it seems like work pretty well.... I don't take segm fault the buffer overrun is silent.

  6. #6
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Okay ..... so you knew the answers to your questions .... why did you bother to ask?

    The nature of several forms of undefined behaviour (including buffer overruns) is that they can't be reliably detected by a compiler. That is a often a large part of the reason the standard leaves the behaviour undefined in the first place.

    The fact you can construct simple examples where it would be technically feasible for a compiler to reliably detect a problem does not mean a compiler can reliably detect all possible instances.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

  7. #7
    Registered User
    Join Date
    Nov 2012
    Posts
    1,393
    Quote Originally Posted by Mr.Lnx View Post
    p.s I would like compiler to inform me that strcpy is dangerous..... it seems like work pretty well.... I don't take segm fault the buffer overrun is silent.
    You can use strncpy instead for a safer alternative

    https://buildsecurityin.us-cert.gov/...g/316-BSI.html

    If you want the compiler to warn you not to use strcpy, you could define a macro

    Code:
    #define strcpy(...) _Static_assert(0, "strcpy is too dangerous to use in this program")

  8. #8
    Registered User
    Join Date
    Jun 2005
    Posts
    6,815
    Recent Microsoft compilers do warn about functions like strcpy(), and even suggest using (Microsoft-specific) safe alternatives.

    Of course, with only a little effort (if doing it deliberately) or by accident, it is possible to use any "safe" function in a dangerous manner.

    The amount of safety that can be built into a programming language, a compiler, or any real system remains finite. Unfortunately, human stupidity (ability to unintentionally do something unsafe) and human malice (ability to intentionally do something unsafe) currently have no known upper bounds.
    Right 98% of the time, and don't care about the other 3%.

    If I seem grumpy or unhelpful in reply to you, or tell you you need to demonstrate more effort before you can expect help, it is likely you deserve it. Suck it up, Buttercup, and read this, this, and this before posting again.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Strcpy function
    By tarunjain07 in forum C Programming
    Replies: 5
    Last Post: 07-29-2011, 11:15 AM
  2. Replies: 1
    Last Post: 06-19-2010, 07:42 AM
  3. problem in my strcpy strcat function
    By genie in forum C Programming
    Replies: 7
    Last Post: 11-07-2008, 09:36 AM
  4. strcpy(pstring, function())
    By kooma in forum C++ Programming
    Replies: 8
    Last Post: 03-03-2002, 04:33 AM
  5. strcpy() function
    By Narciss in forum C Programming
    Replies: 4
    Last Post: 09-21-2001, 12:52 AM