Error c3861 strcpy identifier not found

It doesn’t like the . Try x00 or leave the off.

A string using double quotes automatically includes an null character () at the end. So it is trying to copy 7 characters into 6 spaces, 5 for HELLO and 2 null characters. Avoid using the null character in the string literal.

Just because '' is added automatically doesn’t mean you can’t refer to it explicitly. The code is perfectly legal C, but I suspect the OP is compiling it as C++ where string is very likely to cause issues due to potentially being exposed as a type name.

The code as it stands is fine. A more complete example would help in diagnosing this error.

Try x00 or leave the off.

'' and 'x00' are synonymous.

So it is trying to copy 7 characters into 6 spaces, 5 for HELLO and 2 null characters. Avoid using the null character in the string literal.

strcpy stops copying at the first null character, so the problem you’ve described does not exist.

I suspect the OP is compiling it as C++ where string is very likely to cause issues due to potentially being exposed as a type name.

Why would it be likely to cause issues in C++? g++ doesn’t complain about the OP’s code, even if I add #include <string> and using std::string.

A more complete example would help in diagnosing this error.

Definitely.

g++ doesn’t complain about the OP’s code, even if I add #include <string> and using std::string.

But you didn’t compile the code as it is, because it’s only a snippet; you had to add scaffolding for it to compile. I bet you’re assuming that the OP’s example is something along the lines of this (assuming C++):

#include <string>

using namespace std;

int main()
{
    char string[6];

    strcpy(string, "HELLO");
}

Which compiles just fine in Visual Studio (boo for intrinsics), and probably would in g++ as well. However, it could very easily be this:

#include <string>

using namespace std;

char string[6];

int main()
{
    strcpy(string, "HELLO");
}

Which pukes with an ambiguity error. That’s why more code is needed to diagnose this issue. When using variable names that could potentially be macro or type names, the exact usage is very important.

Which compiles just fine in Visual Studio

TIL: Visual Studio’s <string> header includes <cstring> (or at least somehow declares strcpy). But yes, that’s pretty much what I tried in gcc.

However, it could very easily be this

Interesting, that does indeed cause an error. In fact it produces the exact error message the OP complained about. So that’s almost definitely it.

So I assume the rule is if there’s a type and a variable with the same name, the compiler picks the one with the closer scope (i.e. it will prefer local names over global ones and, presumably, names local to, say, a loop over names local to the whole function) and if the scope is the same, it will always interpret it as a type name? I did not know that. Thank you.

Keep in mind we are dealing with C here and not C++. I wonder if the OP did not include <string.h> for the C prototype of strcpy. The error message is indicating that the compiler is expecting a closing bracket. If you do not include the correct header file, the C compiler usually makes an assumption about the prototype of the function.

In MS-Visual Studio, I get warning C4013: ‘strcpy’ undefined; assuming extern returning int when I leave out the <string.h> header file. I wonder if the OP’s compiler is assuming a one-parameter prototype, like extern int strcpy(char *x) as opposed to extern int strcpy(), which knows nothing about its indefinite number of parameters.

When it reaches the second parameter, perhaps it does not know what to do with it, but this is just speculation. What compiler is being used on what operating system?

Keep in mind we are dealing with C here and not C++.

Just because it’s in the C forum doesn’t mean the OP isn’t using some subset of C++ or compiling as C++. The error strongly suggests that string isn’t being parsed as an object. Given that C++ supports a string type with the name string, it’s not unreasonable to question which language we’re working with here.

I wonder if the OP’s compiler is assuming a one-parameter prototype, like extern int strcpy(char *x) as opposed to extern int strcpy(), which knows nothing about its indefinite number of parameters.

That’s reaching a bit. Any compiler that assumes the former rather than the latter is broken and non-conforming. I know for a fact that Visual C++ is conforming in this case.

Besides, with a mismatch between the call and definition given an implicit declaration, the actual error would happen at link time rather than the compile time syntax error the OP is seeing.

I wonder if the OP’s compiler is assuming a one-parameter prototype

When a function is implicitly declared in C, the inferred prototype will have the same number of arguments as the function call (and all of the arguments’ types will be int).

Also the arity of a function is not information that’s relevant to the parser, so calling a function with the wrong number of arguments can’t cause a parse error. It would produce a «wrong number of arguments» error at a later stage of the compilation.

Whether a given identifier refers to a type on the other hand is relevant to the parser, so that can cause a parse error.

I agree that I am reaching quite a bit with that explanation. Okay, I still have the code I tested as C code, so I will recompile it as C++ and watch what happens.
Time passes
Ah, nuts! I get error C3861: ‘strcpy’: identifier not found under C++ without #include <string.h>. If I include the C header file, it compiles fine and executes as expected. Something else is going on here.

Could the original poster include the rest the function in question? We need more context to be able to diagnose the issue, or at least I do.

With reference to ur query,
int main()
{
char str[6];
clrscr();
strcpy(str,"Hello");
printf("%s",str);
getch();
return 0;
}
whenever we are passing the string (normal string without ) to another string with the help of strcpy() function it will print as it is.
if ur using  at end of the string it is treated as end point,so whenever nul() character is occur it will treat as the termination (end) of the string.