• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            posts - 94, comments - 250, trackbacks - 0, articles - 0
              C++博客 :: 首頁 :: 新隨筆 :: 聯系 :: 聚合  :: 管理

            作者:Michael Howard
            原文出處:Strsafe.h: Safer String Handling in C

              在微軟公司舉行的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》
            這些新函數包含在一個頭文件和一個函數庫(可選)中,而后兩者能在新版的 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》。

            Feedback

            # re: Strsafe.h:更安全的C語言字符串處理函數  回復  更多評論   

            2009-06-23 08:38 by ufo
            (web server軟件)UFO不會出現一個字節的內存泄漏和一個線程的不能回收,使用UFO做Web Server的好處是網站能做得很穩定,永遠也不會自己down掉;UFO在托管機房丟包率很高、遭受Hacker攻擊、互聯網 骨干網被黑等惡劣的環境條件下仍然能很好地運行;UFO在對付Hacker方面(防Hacker弄down和Hacker抓取不該訪問的資源)也有足夠措施。
            另外,UFO幾乎不會進行垃圾回收,消耗CPU很少,在普通的PC Server上用UFO運行網站,平時CPU占用率<0.1%,最多時也不會超 過5%。您知道,JVM的垃圾回收會導致大量的運算,消耗很多CPU,從而導致Server的負載能力和響應速度下降。UFO在對象管理方面采 用了很好的機制和算法,做得很出色。用UFO運行網站,可以一直保證高負載能力,快速的響應速度和低CPU消耗。發布網址:www.gm365.com
            久久婷婷国产麻豆91天堂| 精品熟女少妇aⅴ免费久久| 国产成人综合久久精品红| 亚洲中文字幕无码一久久区| 久久久久亚洲AV无码专区体验| 国产精品99久久久久久人| 国产精品久久久天天影视香蕉| 欧洲国产伦久久久久久久| 人人狠狠综合久久88成人| 久久精品无码一区二区三区日韩| 久久人做人爽一区二区三区| 久久久久综合网久久| 国产欧美久久久精品影院| 久久99中文字幕久久| 久久精品国产亚洲AV香蕉| 色综合久久久久网| 伊人久久综合无码成人网 | 69久久夜色精品国产69| 久久久噜噜噜久久| 99精品久久精品| 久久精品国产男包| 思思久久99热免费精品6| 免费观看成人久久网免费观看| 一本色道久久88—综合亚洲精品| 久久国产V一级毛多内射| 粉嫩小泬无遮挡久久久久久| 久久天天躁狠狠躁夜夜2020一| 久久99精品久久久久久水蜜桃| 国产午夜精品久久久久免费视| 精产国品久久一二三产区区别| 久久av高潮av无码av喷吹| 四虎国产永久免费久久| 999久久久无码国产精品| 色欲综合久久中文字幕网| 2021国内精品久久久久久影院| 久久久久国产一级毛片高清板| 国产精品99久久精品爆乳| 亚洲国产精品久久久久网站| 青青青青久久精品国产h| 精品久久777| 韩国三级中文字幕hd久久精品 |