This year our team decided to migrate from Visual Studio 6 to Visual Studio 2005. At first we planned to make use of the new Secure CRT functions. This may have been a premature decision. Some developers decided to pass on this change. In effect, most of the string functions have new secure counterparts. An example is that there is a new strcpy_s function that is similar to the old strcpy. The new version takes an extra parameter that represents the size of the destination buffer.In theory I guess the Secure CRT functions are a good idea. You hear a lot of stories about malicious users taking advantage of buffer overflows to attack a system. However we have a number of developers who are not strong in C/C++ development. It was difficult for them to grasp how one should pass a length to the Secure CRT functions. Many errors were introduced when they passed in the size of the pointer instead of the length of the memory that the pointer referenced.
I have not dug much into the implementation of the Secure CRT functions except when there were errors. You would think that there is an overhead associated with counting each character in a string operation. There is no easy way to tell whether there is too long of a string being copied into a destination location unless you actually count the input string. At times I have wondered whether you can mix the secure and non-secure string functions together. My theory is that this is not a problem, since a string is a string is a string.
It surprised me that I had not heard much about these Secure CRT functions before attempting to port to Visual Studio 2005. Or maybe other developers had mentioned it. But until you actually have to deal with it, “Secure CRT” really does not mean anything to you. The good news is that the old versions of the string functions have only been deprecated. They can still be used. It will only cause some compiler warnings to be generated. And you can choose to turn those off if you like.
