From: RB on
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
"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
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
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
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 )