Prev: Problem when defining my own string.h
Next: VirtualAlloc,GlobalAlloc,HeapAlloc,..what to use in my case,...
From: Chuck Chopp on 6 Mar 2008 16:53
When building some portable cross-platform code in a .cpp file, I get the
following warning at build time:

c:\projects\test01.cpp(887) : warning C4996: 'vsprintf': This function or
variable may be unsafe. Consider using vsprintf_s instead. To disable
deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.

This occurs with Visual C/C++ v9.0 [VS2008].

The actual warning itself isn't a problem, and the corresponding risk of
buffer overrun is understood, too.

What I'm actually interested in, is how do I generate similar such warnings
at build time if, say, one particular function out of 100's of functions in
one of our own internal utility routine modules gets referenced in one of
our own applications? Is there a special #pragma that will generate such a
warning only if a function name gets referenced by code being built in
another module?

I know that I could do a search across all source code modules to get a
snapshot in time of all existing code, for purposes of doing some
refactoring at a later time, but it would be terribly convenient to get
these types of warnings at build time about references to deprecated
functions. It would certainly allow for existing code to be built OK, but
with a reminder that usage of certain functions should be replaced with
usage of other functions.


TIA,

Chuck
--
Chuck Chopp

ChuckChopp (at) rtfmcsi (dot) com http://www.rtfmcsi.com

RTFM Consulting Services Inc.
103 Autumn Hill Road
Greer, SC 29651

Do not send me unsolicited commercial email.
From: Doug Harrison [MVP] on 6 Mar 2008 17:20
On Thu, 06 Mar 2008 16:53:04 -0500, Chuck Chopp <ChuckChopp(a)rtfmcsi.com>
wrote:

>When building some portable cross-platform code in a .cpp file, I get the
>following warning at build time:
>
>c:\projects\test01.cpp(887) : warning C4996: 'vsprintf': This function or
>variable may be unsafe. Consider using vsprintf_s instead. To disable
>deprecation, use _CRT_SECURE_NO_WARNINGS. See online help for details.
>
>This occurs with Visual C/C++ v9.0 [VS2008].
>
>The actual warning itself isn't a problem, and the corresponding risk of
>buffer overrun is understood, too.
>
>What I'm actually interested in, is how do I generate similar such warnings
>at build time if, say, one particular function out of 100's of functions in
>one of our own internal utility routine modules gets referenced in one of
>our own applications? Is there a special #pragma that will generate such a
>warning only if a function name gets referenced by code being built in
>another module?
>
>I know that I could do a search across all source code modules to get a
>snapshot in time of all existing code, for purposes of doing some
>refactoring at a later time, but it would be terribly convenient to get
>these types of warnings at build time about references to deprecated
>functions. It would certainly allow for existing code to be built OK, but
>with a reminder that usage of certain functions should be replaced with
>usage of other functions.

#pragma deprecated:
http://msdn2.microsoft.com/en-us/library/c8xdzzhh(VS.80).aspx

__declspec(deprecated):
http://msdn2.microsoft.com/en-us/library/044swk7y(VS.80).aspx

--
Doug Harrison
Visual C++ MVP
From: Scott Seligman on 6 Mar 2008 17:23
ChuckChopp(a)rtfmcsi.com wrote:
>
>What I'm actually interested in, is how do I generate similar such warnings
>at build time if, say, one particular function out of 100's of functions in
>one of our own internal utility routine modules gets referenced in one of
>our own applications? Is there a special #pragma that will generate such a
>warning only if a function name gets referenced by code being built in
>another module?

Add __declspec(deprecated) to the function's declaration.

--
--------- Scott Seligman <scott at <firstname> and michelle dot net> ---------
I do not feel obliged to believe that the same God who has endowed us
with sense, reason, and intellect has intended us to forgo their use.
-- Galileo Galilei
From: Igor Tandetnik on 6 Mar 2008 17:17
Chuck Chopp <ChuckChopp(a)rtfmcsi.com> wrote:
> What I'm actually interested in, is how do I generate similar such
> warnings at build time

__declspec(deprecated)

http://msdn2.microsoft.com/en-us/library/044swk7y.aspx

--
With best wishes,
Igor Tandetnik

With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea. It is hard to be sure where they are going to
land, and it could be dangerous sitting under them as they fly
overhead. -- RFC 1925


From: Nathan Mates on 6 Mar 2008 17:24
In article <unBG1R9fIHA.748(a)TK2MSFTNGP04.phx.gbl>,
Chuck Chopp <ChuckChopp(a)rtfmcsi.com> wrote:
>What I'm actually interested in, is how do I generate similar such
>warnings at build time if, say, one particular function out of 100's
>of functions in one of our own internal utility routine modules gets
>referenced in one of our own applications? Is there a special
>#pragma that will generate such a warning only if a function name
>gets referenced by code being built in another module?

I don't think so, but you could fake it pretty easily with
preprocessor macros. For example, you could define MYPROJ_INTERNAL
(rename MYPROJ as appropriate) in the preprocessor defintions for that
project. And, in the headers you want to protect, do something like

#ifndef MYPROJ_INTERNAL
#pragma message("FIXME: Internal item referenced outside of MYPROJ"
#endif

The above will simply print a message in the output window along
with the other build output. You can then quickly search that window
(ctrl-I for incremental search is your friend, just like in the code
editing window.) There's a lot you can do with preprocessor fun.

Nathan Mates
--
<*> Nathan Mates - personal webpage http://www.visi.com/~nathan/
# Programmer at Pandemic Studios -- http://www.pandemicstudios.com/
# NOT speaking for Pandemic Studios. "Care not what the neighbors
# think. What are the facts, and to how many decimal places?" -R.A. Heinlein
 |  Next  |  Last
Pages: 1 2
Prev: Problem when defining my own string.h
Next: VirtualAlloc,GlobalAlloc,HeapAlloc,..what to use in my case,...