From: RB on 27 Apr 2010 14:41 Hello, I am curious as to how my MS VS Pro ver 6.0 sp5 has gained data to give me the following suggestion in the error readout. In other words I had to download and install the PlatformSDK Feb 2003 version to even give my VS the ability to use the strsafe lib. So now that I have implemented the StringCchCopy function to replace strcpy, I get the following error and suggestive msg on a line I had sprintf on. Which is great, and I can accommodate the suggestion gladly, I am just curious how did my compiler know to give me this suggestion on this error ?? Instead of just telling me that I had an "undeclared identifier" which is what I find when I look up the error in my VS error lookup, the compiler now actually tells me this additional strsafe function suggestion, that is not found anywhere in the error lookup data ? ----------compile results paste Compiling... Loan2View.cpp Z:\PROGRAMMING\VC_6_Projects\Loan2\Loan2View.cpp(164) : error C2065: 'sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA' : undeclared identifier Loan2.exe - 1 error(s), 0 warning(s)
From: Tom Walker on 27 Apr 2010 15:02 "RB" <NoMail(a)NoSpam> wrote in message news:#R$g$kj5KHA.5952(a)TK2MSFTNGP04.phx.gbl... > Hello, I am curious as to how my MS VS Pro ver 6.0 sp5 has gained data to > give > me the following suggestion in the error readout. In other words I had to > download > and install the PlatformSDK Feb 2003 version to even give my VS the > ability to use > the strsafe lib. So now that I have implemented the StringCchCopy > function to replace > strcpy, I get the following error and suggestive msg on a line I had > sprintf on. > Which is great, and I can accommodate the suggestion gladly, I am just > curious how > did my compiler know to give me this suggestion on this error ?? Instead > of just telling > me that I had an "undeclared identifier" which is what I find when I look > up the error > in my VS error lookup, the compiler now actually tells me this additional > strsafe function > suggestion, that is not found anywhere in the error lookup data ? > ----------compile results paste > Compiling... > Loan2View.cpp > Z:\PROGRAMMING\VC_6_Projects\Loan2\Loan2View.cpp(164) : error C2065: > 'sprintf_instead_use_StringCbPrintfA_or_StringCchPrintfA' : undeclared > identifier > Loan2.exe - 1 error(s), 0 warning(s) In strsafe.h, there is this define: #define sprintf sprintf_instead_use_StringCchPrintfA_or_StringCbPrintfA; So all occurrences of sprintf will be substituted with a symbol that causes a compiler error. This is to help you find and replace all occurrences of sprintf with the safer functions.
From: Doug Harrison [MVP] on 27 Apr 2010 15:26 On Tue, 27 Apr 2010 12:02:58 -0700, "Tom Walker" <nobody(a)example.com> wrote: >In strsafe.h, there is this define: > >#define sprintf sprintf_instead_use_StringCchPrintfA_or_StringCbPrintfA; > >So all occurrences of sprintf will be substituted with a symbol that causes >a compiler error. This is to help you find and replace all occurrences of >sprintf with the safer functions. And for these Windows-level "safe" functions, be sure to check return codes, as otherwise any errors they catch will go unnoticed until some later time. At least the CRT-level "safe" functions crash the program by default, which is good, because in general, people expect string functions to succeed and don't check return codes. Note also that if one validates parameters before using string functions, which competent programmers always have done, the "safe" functions have no reason to exist, especially the Windows-level ones that require checking return codes. And people certainly shouldn't feel all warm and fuzzy just because they see "safe" string functions used everywhere. It's still easy to screw up their parameters if you don't know what you're doing. I remember submitting several such mistakes in MSDN examples after the big "security update" several years ago. The main value of "safe" string functions is making people slow down long enough to hopefully *think* about what they're doing, and by "think" I mean get it right, in which case, they wouldn't need "safe" string functions. :) -- Doug Harrison Visual C++ MVP
From: RB on 27 Apr 2010 19:44 Thanks, I looked in said header file and saw the #pragma depreciated and #defines that the compiler is reading this from. I can now see where it is getting it.
From: RB on 27 Apr 2010 19:56 Thanks Doug I see now where the compiler is reading this from. Also I have a couple of questions if you would be so kind as to comment on. Was (or is ) the older strNcpy just as safe as the newer StringCchCopy, "if the programmer does proper TotalSize / UnitSize checking for the N " ? And when I say "as safe" I am not just talking about making sure the programmer doesn't screw up but also malicious buffer overflow code taking advantage of this type of code. ( keep in mind I understand buffer overflow but do not understand the how it can be used by malicious code insertion )
|
Next
|
Last
Pages: 1 2 3 4 Prev: CRichEditCtrl contents from RTF file Next: Error, Windows Cannot find hcw file |