«

this code sample is taken from "A Book on C"

char s[100];

strcpy (s, "ABC");

....

the compiler issues a warning. Implicitly declaring C library function 'strcpy' with type 'char*(char *,const char *)'

Why does the compiler issue this warning, what does it mean, and what is the fix? compiler is LLVM 3.1

Paavo Helde <> wrote:
> However, this is C, not C++. As you have posted in a C++ newsgroup, here
> is the same code in C++:
>
> #include <string>
> int main() {
> std::string s = "ABC";
> }

Actually it isn't "the same code" because it uses dynamic memory allocation
while the C version didn't.

OTOH, it's a much *safer* version for sure.

On Tuesday, 24 July 2012 20:12:07 UTC-4, gdo...@gmail.com wrote:
> this code sample is taken from &quot;A Book on C&quot;
>
> char s[100];
>
> strcpy (s, &quot;ABC&quot;
>
> ...
>
> the compiler issues a warning. Implicitly declaring C library function 'strcpy' with type 'char*(char *,const char *)'
>
> Why does the compiler issue this warning, what does it mean, and what is the fix? compiler is LLVM 3.1


I guess you were using Clang as the C/C++ front-end. In C
one can declare a function implicitly, by invoking the
function. I presume that Clang is aware of the standard
function 'strcpy', and issued a warning that you implicitly
declared a C library function.

Solution: have the 'string.h' header included in your
relevant source code file(s).


PS: this is a very common problem, you should have used
Google first.

-- Zoltan

U missing header file to find the forward declaration of strcpy.

On Wed, 2012-07-25, Juha Nieminen wrote:
> Paavo Helde <> wrote:
>> However, this is C, not C++. As you have posted in a C++ newsgroup, here
>> is the same code in C++:
>>
>> #include <string>
>> int main() {
>> std::string s = "ABC";
>> }
>
> Actually it isn't "the same code" because it uses dynamic memory allocation
> while the C version didn't.

[Disregarding that Paavo probably let "the same code" mean "the normal
way to do the corresponding thing in C++"]

I don't quite see why the dynamic allocation difference is noteworthy
here. Both languages support it, and there's nothing wrong with using
it.

> OTOH, it's a much *safer* version for sure.

Yes, and *that's* the difference. Not in this meaningless example of
course, but if you plan to use that string for something non-trivial.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

Jorgen Grahn <grahn+> wrote:
> I don't quite see why the dynamic allocation difference is noteworthy
> here. Both languages support it, and there's nothing wrong with using
> it.

There are many situations where the speed difference is significant.

On Thu, 2012-07-26, Juha Nieminen wrote:
> Jorgen Grahn <grahn+> wrote:
>> I don't quite see why the dynamic allocation difference is noteworthy
>> here. Both languages support it, and there's nothing wrong with using
>> it.
>
> There are many situations where the speed difference is significant.

Yes, sure, but they are not so common that you go for char[N] by
default. (Also we shouldn't scare away C newbies by immediately
warning them about the inefficiencies of std::string.)

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .