Click here to Skip to main content
Rate this: bad
good
Please Sign up or sign in to vote.
See more: VC6 C++
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 3:46am
pjhelp515
Edited 18-Apr-11 4:52am
v3
Comments
Kozlov_Sergey at 18-Apr-11 9:55am
   
It can be dangerous following Microsoft because symbol '\0' defines the end of the string.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 2

Simply use strcpy_s[^] to avoid the warning.
 
I can also suggest you to use std::string, or CString to simplify things.
  Permalink  
Comments
SafarTimura at 18-Apr-11 9:29am
   
like changing the function warning removal is rarely a good idea.
 
J
Niklas Lindquist at 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.
SafarTimura at 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 Lindquist at 18-Apr-11 11:33am
   
Ah! Lost in translation. Sorry. ...and thanks!
SAKryukov at 18-Apr-11 23:36pm
   
Correct answer, would agree on std (but hardly on CString), my 5.
--SA
Niklas Lindquist at 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.
SAKryukov at 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
Rate this: bad
good
Please Sign up or sign in to vote.

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);
  Permalink  
Comments
SAKryukov at 18-Apr-11 23:37pm
   
He he he. A 5.
--SA
Rate this: bad
good
Please Sign up or sign in to vote.

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.
  Permalink  
Comments
SAKryukov at 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 at 19-Apr-11 3:52am
   
Thanks, OP is fairly new so probably still learning the protocol.
SAKryukov at 19-Apr-11 4:05am
   
Some horse sense would do as well...
--SA
Rate this: bad
good
Please Sign up or sign in to vote.

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
  Permalink  
Comments
Hans Dietrich at 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.
Rate this: bad
good
Please Sign up or sign in to vote.

Solution 1

To quote your own message:
 
To disable deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
  Permalink  
Comments
Hans Dietrich at 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 Lindquist at 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 at 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 Lindquist at 18-Apr-11 12:06pm
   
Yes, but with strncpy() being the odd exception.
 
Nice link btw.
krmed at 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 at 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.

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



Advertise | Privacy | Mobile
Web03 | 2.8.1411022.1 | Last Updated 19 Apr 2011
Copyright © CodeProject, 1999-2014
All Rights Reserved. Terms of Service
Layout: fixed | fluid

CodeProject, 503-250 Ferrand Drive Toronto Ontario, M3C 3G8 Canada +1 416-849-8900 x 100