C4996 (function unsafe) warning for strcpy but not for memcpy

Question

I am writing code in VS2010 and I happen to see after compilation compiler gives me C4996 warning (\"This function or variable may be unsafe\") for strcpy and sprintf calls.

Answer 1

In general, to compile C code you need a conforming C compiler. Visual Studio is a non-conforming C++ compiler.

You get the warning because Visual Studio is bad. See this.

C4996 appears whenever you use a function that Microsoft regards as obsolete. Apparently, Microsoft has decided that they should dictate the future of the C language, rather than the ISO C working group. Thus you get false warnings for perfectly fine code. The compiler is the problem.

There is nothing wrong with the strcpy() function, that's a myth. This function has existed for some 30-40 years and every little bit of it is properly documented. So what the function does and what it does not should not come as a surprise, even to beginner C programmers.

What strcpy does and does not:

• It copies a null-terminated string into another memory location.
• It does not take any responsibility for error handling.
• It does not fix bugs in the caller application.
• It does not take any responsibility for educating C programmers.

Because of the last remark above, you must know the following before calling strcpy:

• If you pass a string of unknown length to strcpy, without checking its length in advance, you have a bug in the caller application.
• If you pass some chunk of data which does not end with \0, you have a bug in the caller application.
• If you pass two pointers to strcpy(), which point at memory locations that overlap, you invoke undefined behavior. Meaning you have a bug in the caller application.

For example, in the code you posted, you never initialized the arrays, so your program will likely crash and burn. That bug isn't in the slightest related to the strcpy() function and will not be solved by swapping out strcpy() for something else.

Answer 2

You get these warning because not passing the length of string and relying on \0 termination are unsafe as they may cause buffer overrun. In memcpy you pass length so no overrun issue.

You can use something like

#ifdef _MSC_VER
#  pragma warning(push)
#  pragma warning(disable:4996)
#endif
strcpy... ;  // Code that causes unsafe warning
#ifdef _MSC_VER
#  pragma warning(pop)
#endif

If you don't worry about portability, you can use alternatives like strcpy_s etc

Answer 3

The warning meens that the function is deprecated and will not be available in future versions: http://msdn.microsoft.com/en-US/en-en/library/ttcz0bys.aspx You can't add other functions to the deprecate list of Microsoft.

The reason for the deprecation are "unsafe", but that's different from your assumption "C4496 shows you all unsafe functions".

Answer 4

strcpy is unsafe if the terminating NUL is missing, as it may copy more characters than fit in the destination area. With memcpy, the number of bytes copied is fixed.

The memcpy_s function actually makes it easier for programmers to do it wrong -- you pass two lengths, and it uses the smaller of both, and all you get is an error code that can be silently ignored with no effort. Calling memcpy requires filling out the size parameter, which should make programmers think about what to pass.

Answer 5

Include in header "stdafx.h" definition

#define _CRT_SECURE_NO_WARNINGS

As for the difference of strcpy and memcpy then the last function has third parameter that explicitly specifies how many characters must be copied. The first function has no information how many characters will be copied from the source string to the destination string so in general case there is a possibility that the memory allocated for the destination string will be overwritten.

Answer 6

Because strcpy and sprintf really are unsafe functions, it depends on the content of the string to not overflow. Instead you should use strncpy and snprintf to make sure it does not overwrite the memory.

While memcpy is not this case, it has the length so it does not overwrite memory as long as the length is correct.