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 ?

The "documentation" is correct in your first example.

Your second example is not recursion.

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.

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.

Quote:

---

Originally Posted by dwks

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.

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.

Quote:

---

Originally Posted by Mr.Lnx

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")

---

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.