any idea on how to change strcpy in c++

int main()
{
    //all the winning combination
    strcpy(winKey[1].key, "123");
    strcpy(winKey[2].key, "456");
    strcpy(winKey[3].key, "789");
    strcpy(winKey[4].key, "147");
    strcpy(winKey[5].key, "258");
    strcpy(winKey[6].key, "369");
    strcpy(winKey[7].key, "159");
    strcpy(winKey[8].key, "357");
    }

Dani AI

Generated

A short, practical summary and safe alternatives to the strcpy warning shown by .

The Visual C++ warning you saw (C4996: "This function or variable may be unsafe") is MSVC telling you that plain strcpy does no bounds checking and so is easy to misuse; MSVC suggests safer replacements or lets you suppress the diagnostic if you understand the risks. (learn.microsoft.com)

Prefer idiomatic C++: store and assign strings with std::string instead of raw char[]. That removes manual buffer-management entirely and makes the code clearer and safer. Example pattern (replace your char member with an owning string type):

#include <string>
#include <array>

std::array<std::string,8> winKeys = {
    "rowA","rowB","rowC","colA","colB","colC","diagA","diagB"
};

std::basic_string is the standard C++ string type and handles allocation, copying, and lifetime for you. (en.cppreference.com)

If a C-style buffer is required (interop, legacy API), copy safely and always enforce a size limit and a terminating NUL. Prefer snprintf or explicit bounded-copy + manual NUL rather than raw strcpy. Example:

char buf[16];
std::snprintf(buf, sizeof(buf), "%s", winKeys[i].c_str()); // truncates, leaves NUL

snprintf guarantees the buffer is NUL-terminated when buf_size > 0. Avoid strncpy unless you understand its padding / non-termination semantics. (en.cppreference.com)

If building for MSVC and you want MS's "secure" API, strcpy_s exists and enforces a destination-size parameter (and has C++ template overloads), but it’s Microsoft/C11-style and less portable than std::string. Use it only when you need that CRT behavior. (learn.microsoft.com)

Notes tied to the thread: and are correct that MSVC offers ways to suppress the warning; that’s useful for quick experiments, but converting to std::string (or using a bounded-copy approach) is the more robust, long-term fix.

Recommended Answers

All 11 Replies

What?? what do you mean by "changing" here??

1) You don't -- this is the C forum.

2) Set insert mode off, set the cursor on the s, and type.

when i runs it shows error like :
warning C4996: 'strcpy': This function or variable may be unsafe. Consider using strcpy_s instead. To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

is there any alternative to it?

Yes, turn off the error message for the compiler. M$ has decided to rewrite the function, but since the function they wrote is not standard, they also decided to annoy us with their "we're better than the standard" attitude.

commented: hahaha! nice ;) +2

is there any alternative to it?

Well, you could read the message and see that strcpy_s() is provided as a "safe" alternative. strcpy_s() is a part of the C11 standard (it's not standard at all in C++), but C11 was only ratified in January of this year, so there aren't any solid implementations of it yet.

But Microsoft bugged us with that stupid warning long before the bounds checked functions were included in C11, and C11 doesn't deprecate the non-range checked functions, so it doesn't excuse the warning at all. I always disable it from the project settings (Configuration Properties -> C/C++ -> Advanced -> Disable Specific Warnings). You can also disable it directly from code with this pragma:

#pragma warning(disable:4996)

But that hurts your code's portability.

I don't use VC at this time but doesn't VC offer a way to disable errors from the project/IDE settings? If not, that figures...

I don't use VC at this time but doesn't VC offer a way to disable errors from the project/IDE settings?

In my previous post I described both a project settings method and a direct code method for disabling warnings.

Member Avatar for Member #957352

seriously, after reading discussions on Daniweb.com increases my knowlegde much. You all guys are great. by heart i am saying. hats off to all. thanks.

Sorry, missed the first method and zeroed in just on the pragma...

Sorry, missed the first method and zeroed in just on the pragma...

To be fair, pragmas are evil. Sometimes necessary, but always evil. ;)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.