How to avoid an warning message related to "strcpy()"?

Question

1.30/5 (3 votes)

See more:

static char BASED_CODE szFilter[] = "HTML Files (*.xls)|*.xls|All Files (*.*)|*.*||";
 
    if (AppMarketID == 12)
    { 
      strcpy(szFilter,"HTML Files (*.xlsx)|*.xlsx|All Files (*.*)|*.*||");     
    }
CFileDialog dia(FALSE, "", default_name, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, szFilter);

I’m getting Warning as -

 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.

Can you please guide me how I can avoid this Warning?
Thank you .

Posted 18-Apr-11 2:46am

pjhelp

Updated 11-Jan-18 8:18am

Kozlov_Sergey

v3

Add a Solution

Comments

[no name] 18-Apr-11 9:55am

It can be dangerous following Microsoft because symbol '\0' defines the end of the string.

6 solutions

Solution 2

Simply use strcpy_s[^] to avoid the warning.

I can also suggest you to use std::string, or CString to simplify things.

Posted 18-Apr-11 3:03am

Niklas L

Comments

Guyverthree 18-Apr-11 9:29am

like changing the function warning removal is rarely a good idea.

J

Niklas L 18-Apr-11 11:21am

And why is it not a good idea to change the function if you get a warning? The warnings are there for a reason. Too many programmers have made too many errors involving strcpy and buffer overflows over the years. Microsoft decided to do something about it, promoting the new 'secure' versions of the old string manipulation functions. This is actually what Microsoft recommends.

Guyverthree 18-Apr-11 11:31am

Sorry it was a badly written comment.

It should have said: I like changing the function, warning suppression is rarely a good idea.

I agree that changing the function is the right thing to do, rather than just suppressing the warning like the other solutions. I voted 5. :)

Niklas L 18-Apr-11 11:33am

Ah! Lost in translation. Sorry. ...and thanks!

Sergey Alexandrovich Kryukov 18-Apr-11 23:36pm

Correct answer, would agree on std (but hardly on CString), my 5.
--SA

Niklas L 19-Apr-11 3:01am

Well, it is MFC after all. Actually, the worst way is to use a static char*. The example on MSDN uses a static char*, and it's easy to use. But what happens the day you want to localize your app? A CString::LoadString() would be a lot better. But I agree, I prefer std::string over CString whenever I can. Thanks for the 5.

Sergey Alexandrovich Kryukov 19-Apr-11 3:13am

I actually noticed that some time after I posted my comment on CString. In this case, this is a sufficient justification; would not be for a good universal code -- better be portable.
Thank you.
--SA

Solution 6

There is no reason to use strcpy at all in this case, especially since you are dealing with static strings:

static char BASED_CODE szFilter1[] = "HTML Files (*.xls)|*.xls|All Files (*.*)|*.*||";
static char BASED_CODE szFilter2[] = "HTML Files (*.xlsx)|*.xlsx|All Files (*.*)|*.*||";
CFileDialog dia(FALSE, "", default_name, OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, (AppMarketID == 12) ? szFilter2 : szFilter1);

Posted 18-Apr-11 3:52am

Hans Dietrich

Comments

Sergey Alexandrovich Kryukov 18-Apr-11 23:37pm

He he he. A 5.
--SA

Solution 4

Project properties->Configuration Properties->C/C++->Preprocessor->Preprocessor Definitions
Click on the elipses (...)
type any definitions you like separated by "\n"ie
_CRT_SECURE_NO_WARNINGS

Posted 18-Apr-11 3:10am

cute_friend7077

Comments

Hans Dietrich 18-Apr-11 9:57am

In general, unless there is no alternative, it's a Bad Idea to change the project properties just because of what's in a source file. What if you were to take the source file and use it in another project, months from now? Then you would have to spend time trying to figure out why you get the warning on one project, but not another. Even worse, what if someone else changed the properties, and you were not aware of it? Waste of time.

Solution 1

To quote your own message:

SQL

To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

Posted 18-Apr-11 2:51am

krmed

Comments

Hans Dietrich 18-Apr-11 10:05am

Since this is usually specified in stdafx.h and not in the source file, it is a Bad Idea. What if you were to take the source file and use it in another project, months from now? Then you would have to spend time trying to figure out why you get the warning on one project, but not another. If you want to be proactive about this warning, then do what I do; put this pragma at the top of each source file where needed:
#pragma warning(disable : 4996) // disable bogus deprecation warning
Note that I say "bogus" because that's exactly what it is; you can achieve the same effect from using strncpy(). Yes, you can be wrong about the length parameter in strncpy, just like you can be wrong about the length parameter in strcpy_s. With both functions, you have to be careful.

Niklas L 18-Apr-11 11:08am

strncpy() does not guarantee a null terminator in the target string if the buffer is full which is a real problem. So strncpy() is also tagged insecure.
The template versions of strcpy_s() working on arrays are quite nice however.

Hans Dietrich 18-Apr-11 11:40am

The standard practice when working with "unknown" strings is to set the last character to zero after the copy. (I see this done on Unix more than on Windows.) Yes, the _s functions are nice this way, but to claim they are safe is a joke. See for example, Danny Kalev's analysis here:
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=260

Niklas L 18-Apr-11 12:06pm

Yes, but with strncpy() being the odd exception.

Nice link btw.

krmed 18-Apr-11 10:16am

I didn't say it was a good idea, just answered the OP's question. How can I avoid...
In my opinion (and what I've always done) the appropriate solution is to use strcpy_s (or _tcscpy_s).

strncpy isn't really equivalent since it doesn't append the null at the end of the string, whereas strcpy_s does append it, and makes sure there is room for the terminating null.

krmed 19-Apr-11 6:50am

I would think that if someone downvotes an answer they should at least add a comment as to why they feel that way. It's almost enough to discourage anyone from posting any answers.

Solution 7

The quickest solution would be adding

#pragma warning(disable:4996)

to

HTML

stdafx.h

This isn't the best solution and this warning is here for a reason, but if this error messages delays you and you must eliminate it ASAP, that's what you have to do.

Posted 11-Jan-18 8:17am

Michael Haephrati

Comments

CPallini 11-Jan-18 15:30pm

That delayed the OP for seven long years. :-)

Michael Haephrati 11-Jan-18 15:35pm

I am sure 7 good years are now to come :)

CHill60 12-Jan-18 8:45am

No different to the comment added to solution 1 that was offered 7 years ago, so was it really worth resurrecting such an old post?

Michael Haephrati 12-Jan-18 8:47am

Just to explain further, when I select "Unanswered questions" or search for questions (for example, in c/ c++) I get to this and other questions regardless of their date. If this is a conceptual bug, it should be changed. I was just trying to help...

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Richard MacCutchan · Accepted Answer · 2011-04-18T03:49:00

Solution 5

You have now posted this same question three times: here[^], here[^], and here. You have also been given some useful suggestions as to how to resolve it. Maybe it's time you went and read up on the basics of pointers and arrays, and their differences, and why strcpy() can be dangerous.

Posted 18-Apr-11 3:49am

Richard MacCutchan

Comments

Sergey Alexandrovich Kryukov 18-Apr-11 23:40pm

...and also down-voted this Answer by 1 (maybe, not OP though; I voted 5).
I totally agree with you.

OP should be advised: the re-posts should be removed, repeated re-posting will be reported as spam and abuse for moderation measures.

--SA

Richard MacCutchan 19-Apr-11 3:52am

Thanks, OP is fairly new so probably still learning the protocol.

Sergey Alexandrovich Kryukov 19-Apr-11 4:05am

Some horse sense would do as well...
--SA