Click here to Skip to main content
16,015,296 members
Please Sign up or sign in to vote.
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
Updated 11-Jan-18 8:18am
v3
Comments
[no name] 18-Apr-11 9:55am    
It can be dangerous following Microsoft because symbol '\0' defines the end of the string.

Simply use strcpy_s[^] to avoid the warning.

I can also suggest you to use std::string, or CString to simplify things.
 
Share this answer
 
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
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);
 
Share this answer
 
Comments
Sergey Alexandrovich Kryukov 18-Apr-11 23:37pm    
He he he. A 5.
--SA
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.
 
Share this answer
 
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
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
 
Share this answer
 
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.
To quote your own message:

SQL
To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
 
Share this answer
 
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.
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.
 
Share this answer
 
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...

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900