原文出處：Strsafe.h: Safer String Handling in C：http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsecure/html/strsafe.asp
在微軟公司舉行的Microsoft Windows Security Push 活動期間，一批測試者、程序管理經理和普通程序員共同決定要為 C 語言量身定制一套具有較高安全性的字符串處理函數，並且希望這些函數能被 Windows 程序員和微軟公司內部的程序員所采用。
簡單說來，現有的 C 語言運行時函數實在難以在當今充斥著惡意攻擊企圖的大環境下立足。這些函數要麼在返回值和參數上缺乏一致性，要麼隱含著所謂的“截斷誤差”(truncation errors) 錯誤，要麼無法提供足夠強大的功能。坦言之，調用這些函數的代碼太容易產生“內存溢出”問題了。
我們發現，面向 C++ 程序員的類足以應付各種安全處理字符串的編程需要；他們能夠選擇 MFC 的Cstring 類、ATL 的CComBSTR 類 或者STL 的string 類，等等。然而，經典的 C 語言程序仍然普遍地存在，何況許多人正在把 C++ 當作 “改良的 C 語言” 來用，卻把豐富的 C++ 類束之高閣。
其實只需要添加一行代碼，你就能在 C 語言代碼中調用安全性良好的 strsafe 系列函數了，詳細請參閱：
《Using the Strsafe.h Functions》：http://msdn.microsoft.com/en-us/library/ms647466.aspx
這些新函數包含在一個頭文件和一個函數庫(可選)中，而後兩者能在新版的 Platform SDK 中找到。對，就這麼簡單：
#include "strsafe.h"
還等什麼呢！
再強調一次，對 strsafe 函數庫的引用是可選的。
為了實現 strsafe 系列函數的目標，你的代碼必須滿足下列條件：
始終以 NULL 字符結束字符串。
始終檢測目標緩沖區的長度。
始終用 HRESULT 語句產生統一的返回值。
兼顧 32 位與 64 位兩種運行環境。
具有靈活性。
我們覺得，缺乏統一性是導致現有許多 C 語言字符串處理函數容易產生安全漏洞的根本原因，而 strsafe 系列函數所帶來的高度統一性恰恰是解決此問題的一劑良藥。然而，strsafe 也不是萬能藥。單純依靠 strsafe 系列函數並不能保證代碼的安全性和堅固性——你還必須開動你的大腦才行——然而這樣對解決問題還是大有幫助的！
下面給出一段采用經典 C 語言運行時間函數的代碼：
void UnsafeFunc(LPTSTR szPath,DWORD cchPath) {
TCHAR szCWD[MAX_PATH];
GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD);
strncpy(szPath, szCWD, cchPath);
strncat(szPath, TEXT("\\"), cchPath);
strncat(szPath, TEXT("desktop.ini"),cchPath);
}
以上代碼中的 bug 隨處可見 —— 它沒有檢查任何一個返回值，而且在對 strncat 函數的調用中也沒有正確地使用 cchPath (因為MAX_PATH 中保存的是目標緩沖區內剩余空間的長度，而不是目標緩沖區的總長度)。於是，“內存溢出” 問題將會快找上門來。然而，象這樣的代碼片段早已泛濫成災了。如果改用 strsafe 系列函數，那麼以上代碼應該變成：
bool SaferFunc(LPTSTR szPath,DWORD cchPath) {
TCHAR szCWD[MAX_PATH];
if (GetCurrentDirectory(ARRAYSIZE(szCWD), szCWD) &&
SUCCEEDED(StringCchCopy(szPath, cchPath, szCWD)) &&
SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("\\"))) &&
SUCCEEDED(StringCchCat(szPath, cchPath, TEXT("desktop.ini")))) {
return true;
}
return false;
}
這段代碼不但檢查了每一個返回值，還保證了適時傳入同一目標緩沖區的總長度。你還可以采用 Ex 版本的 strsafe 系列函數來實現更加高級的功能，比如：
獲取目標緩沖區的當前指針。
獲取目標緩沖區的剩余空間長度。
以某個特定字符填充空閒緩沖區。
一旦字符串處理函數失敗，就把用特定值填充字符串。
一旦字符串處理函數失敗，就把目標緩沖區設成 NULL 。
如此改進後的代碼性能又如何呢？告訴你一個好消息：它與原先的代碼在性能上幾乎沒有差別。我曾在自己的 1.8 GHz 電腦上測試過混用經典 C 語言中各種字符串連接函數的代碼、混用 strsafe 系列中各種字符串連接函數的代碼和混用 Ex 版本 strsafe 系列中各種字符串連接函數的代碼。它們各自獨立運行一百萬次(沒錯，就是 10,000,000 次)所消耗的時間分別為：
經典 C 語言 —— 7.3 秒
Strsafe 系列—— 8.3 秒
Strsafe 系列 (Ex 版) —— 11.1 秒
在測試中，調用 Ex 版本的 strsafe 系列函數的程序會在調用失敗時把緩沖區設為 NULL ，並以 0xFE 作為填充字節，代碼如下：
DWORD dwFlags = STRSAFE_NULL_ON_FAILURE | STRSAFE_FILL_BYTE(0xFE);
其中設置填充字節的代碼耗時較多。事實上，如果這裡僅僅把緩沖區設置為 NULL 的話，則采用 Ex 版本的 strsafe 系列函數的代碼將會與采用普通的 strsafe 系列函數的代碼耗時相同。
由此可見，以上三種方案的性能差異極小。我相信你也不會經常在一個程序中數百萬次地反復執行包含大量字符串處理函數的代碼吧！
還有一點值得引起注意：當你引用 strsafe 系列函數時，原有的 C 語言字符串處理函數都將被自動進行 #undef 處理。這也沒問題，因為調試過程中的出錯信息將會告訴你哪些函數已經被相應的 strsafe 系列函數取代了。好了，請放心地使用 strsafe.h 吧！更多相關信息請參閱 《Using the Strsafe.h Functions》（http://msdn.microsoft.com/en-us/library/ms647466.aspx）。
