Is it possible to change the "function call" during preprocessing or compilation time

Question

1st problem: Is it possible to call a function with some parameters, and after compilation it can be changed before compilation either during preprocessing or during compilation into something like

#define func(a,b) func(a,sizeof(a),b) 

Some might wonder why such a need arose.

In fact, I am porting code in windows using visual studio 2010, and there are some functions that are deprecated like strcpy (), strcat (), etc. Instead, it uses strcpy_s () instead.

I know that I could suppress it with #pragma disable(warning: ) or by providing flags like:

 _CRT_NONSTDC_NO_DEPRRECATE _CRT_SECURE_NO_DEPRECATE _CRT_SECURE_NO_WARNINGS 

But I do not want to ignore or suppress them.

I tried just replacing the string instead of ignoring using:

 #define strcpy strcpy_s 

as here http://msdn.microsoft.com/en-us/library/td1esda9.aspx I read that there will be no inconsistency of the arguments if I did not provide the second argument.

I mean this should be fine if I use like this:

 #define strcpy strcpy_s strcpy(dest,src); 

But he is not. It still raises a warning.

Definition of strcpy_s:

 errno_t strcpy_s( char *strDestination, size_t numberOfElements, const char *strSource ); 

Second problem: The first argument is a pointer to dynamically allocated memory, since I can get the size of memory indicated by this pointer. Although I read that this is not possible, there must be some way (hopefully).

By the way, what is _countof(var) ?

Answer 1

These features are NOT deprecated. Microsoft is trying to get you to write Microsoft-specific code by falsely claiming to be outdated, although the ISO WG14 committee (which is responsible for them) has not made such a statement.

The definition of three _CRT macros should be seen as the right way to turn the compiler into a "slightly closer to standard" mode, like /Za .

Answer 2

As indicated by MSalters, these functions arent outdated, they are part of the C standard. They are safe to use correctly, and there is nothing wrong with suppressing these warnings, especially when writing portable code. (They (perhaps only some of them, I don’t know) are standardized in Appendix K of standard C11, which is not mandatory.)

But I do not want to ignore or suppress them.

Why? Not suppressing warnings is not a good thing in itself.

I tried just replacing the string instead of ignoring using:

 #define strcpy strcpy_s 

This only works for C ++ (and only for MS Windows, I don’t know if C ++ indicates something similar to C11s Appendix K) and even there, only for array arguments. In C, you can get a similar behavior:

 #define IS_ARRAY(arr) ((char *)(arr) == (char *)&(arr)) #define my_strcpy(a, b) ( assert(IS_ARRAY(a)) , strcpy_s((a), sizeof(a), (b)) ) 

or even a static statement - for example, Gcc allows this as a constant expression; the standard allows, but does not require this - this will allow you to find all occurrences of the pointer arguments at compile time and "fix" them manually. (Again, this cannot be fixed, either the code is already safe with strcpy , or it still does not work, it most likely will fail.)

As a side note, the behavior is undefined if a macro with the name of the standard library function is defined (if the associated header is included). Thus, I assumed that strcpy calls have already been replaced with my_strcpy .

(For another note, always specify macro arguments as shown above.)