无论是居室还是代码，我们总是有必要不时对其进行认真的清理。不幸的是，在我们开始清理时，总会产生这样的疑惑，那就是这些东西到底来自何方？为什么我们从未注意到它的存在？尽管能够清理部分内容，但总有一些会保留下来。如果您在某些方面与我相像，那么可能还会导致出现更明显、更新奇的问题。57892666435493291647www.xker.com02360221710771653115

我们看一下问题出在什么地方。C 运行库亟待进行有效的改进，这里的改进不是指一般意义上的完善，而是使它具有稳固的结构，使它完全脱胎换骨！

请认真考虑一下此问题。请问人们在什么情况下写出了诸如 strcpy 和 strcat 之类的函数？是很久以前 Kernighan 和 Ritchie 刚刚开发出 C 语言的那段美好时光，那时代码面临的威胁远没有现在严重，网络的互连也远没有现在普及。而现在的情况则让我摸不清头脑，那就是您仍然能够使用诸如 strcpy 的函数写出安全的代码。这就是数据在起作用。但诸如 strcpy 之类的函数本身无法帮助您写出安全的代码，并且在调用这类函数时可能出现灾难性的错误。正如 'Nuff 所说，是的，gets 只是一般的错误！

那么，针对这种情况，我们能够采取什么措施呢？您可能听说过 strsafe.h 文件，该文件中包含了一组一致的、更安全的字符串处理函数，于 2002 年 Windows Security Push 活动期间开发，适用于 Visual Studio® .NET 2003 和 Platform SDK。可以查阅 Strsafe.h:Safer String Handling in C，了解有关 strsafe 的更多信息。

也可以在许多开放源代码的操作系统中使用其他函数（比如，strlcpy 和 strlcat）。可以在 David Wheeler 撰写的 Secure Programming for Linux and Unix HOWTO 一文中查阅这两个函数的有关信息。

尽管开发 strl* 和 strsafe 是一种有效的措施，我们仍然需要在核心的 C 运行库中创建更加可靠的功能，这正是经过更新的 CRT 发挥作用的地方。Microsoft Visual C++® 库开发小组决定跟踪并认真检查 CRT 中的每一个函数，以确定其中是否存在安全性方面的缺陷，找出可能的解决方法。众所周知，为了提高安全性，也为了有助于用户写出更加安全的代码，已经重新编写了许多函数（大约有 400 个左右）。

新版 CRT 的新增功能

首先，本文所介绍的新增加的 CRT 函数将出现在 Visual Studio 2005 中，但最终发行的版本可能与目前的版本有所不同。其次要指出的是，仅仅通过改变编译器的某个参数，新的库不会奇迹般地使得不安全的代码变为安全的代码，但肯定有助于增加代码的安全性。

更安全的可供选择的方法不会取代已有的功能。换言之， strcpy 仍将是 strcpy。它的更加安全的版本具有一个新名称，即 strcpy_s。但是，如果在编译时使用新的库，那么旧版本的函数将失效。所以需要说明的是，编译器会立即向您发出警告信息。也就是说，与修复安全性缺陷相比，改正编译器警告信息所指出的错误要更加容易。请认真考虑我就此问题提出的建议！

某些函数（比如，calloc）仅仅加强了检查参数的工作，其功能与以前的版本完全相同，所以不存在 calloc_s 函数。稍后将介绍有关 calloc 函数的更多信息。

我最赞同的更改是使用 strncat_s 函数代替了 strncat 函数。strncat 函数的问题在于它的最后一个参数不表示目标缓冲区的总的大小，它指示目标缓冲区中剩余的最小缓冲区的大小，以及需要复制的数目。这可能导致各种类型的 off-by-one（差 1）错误，甚至导致更严重的 off-by-lots（差多） 错误。请看下面的例子：

if (szURL != NULL) {

char szTmp[MAX_PATH];

char*szExtSrc, *szExtDst;

strncpy(szTmp, szURL, MAX_PATH);

szExtSrc = strchr(szURL, '.');

szExtDst = strchr(szTmp, '.');

if(szExtDst) {

szExtDst[0] = 0;

if (fValid)

strncat(szTmp, szExtSrc, MAX_PATH);