C語言八大難點揭秘:學(xué)不好編程全賴他們
? 引言
C 和 C++ 程序中的內(nèi)存錯誤非常有害:它們很常見,并且可能導(dǎo)致嚴(yán)重的后果。來自計算機(jī)應(yīng)急響應(yīng)小組(請參見參考資料)和供應(yīng)商的許多最嚴(yán)重的安全公告都是由簡單的內(nèi)存錯誤造成的。自從 70 年代末期以來,C 程序員就一直討論此類錯誤,但其影響在至今年仍然很大。更糟的是,如果按我的思路考慮,當(dāng)今的許多 C 和 C++ 程序員可能都會認(rèn)為內(nèi)存錯誤是不可控制而又神秘的頑癥,它們只能糾正,無法預(yù)防。
但事實并非如此。本文將讓您在短時間內(nèi)理解與良好內(nèi)存相關(guān)的編碼的所有本質(zhì):
? 正確的內(nèi)存管理的重要性
存在內(nèi)存錯誤的 C 和 C++ 程序會導(dǎo)致各種問題。如果它們泄漏內(nèi)存,則運行速度會逐漸變慢,并最終停止運行;如果覆蓋內(nèi)存,則會變得非常脆弱,很容易受到惡意用戶的攻擊。從 1988 年著名的莫里斯蠕蟲攻擊到有關(guān) Flash Player 和其他關(guān)鍵的零售級程序的最新安全警報都與緩沖區(qū)溢出有關(guān):“大多數(shù)計算機(jī)安全漏洞都是緩沖區(qū)溢出”,Rodney Bates 在 2004 年寫道。
在可以使用 C 或 C++ 的地方,也廣泛支持使用其他許多通用語言(如 Java?、Ruby、Haskell、C#、Perl、Smalltalk 等),每種語言都有眾多的愛好者和各自的優(yōu)點。但是,從計算角度來看,每種編程語言優(yōu)于 C 或 C++ 的主要優(yōu)點都與便于內(nèi)存管理密切相關(guān)。與內(nèi)存相關(guān)的編程是如此重要,而在實踐中正確應(yīng)用又是如此困難,以致于它支配著面向?qū)ο缶幊陶Z言、功能性編程語言、高級編程語言、聲明性編程語言和另外一些編程語言的所有其他變量或理論。
與少數(shù)其他類型的常見錯誤一樣,內(nèi)存錯誤還是一種隱性危害:它們很難再現(xiàn),癥狀通常不能在相應(yīng)的源代碼中找到。例如,無論何時何地發(fā)生內(nèi)存泄漏,都可能表現(xiàn)為應(yīng)用程序完全無法接受,同時內(nèi)存泄漏不是顯而易見。
因此,出于所有這些原因,需要特別關(guān)注 C 和 C++ 編程的內(nèi)存問題。讓我們看一看如何解決這些問題,先不談是哪種語言。
? 內(nèi)存錯誤的類別
首先,不要失去信心。有很多辦法可以對付內(nèi)存問題。我們先列出所有可能存在的實際問題:
這是所有類型。即使遷移到 C++ 面向?qū)ο蟮恼Z言,這些類型也不會有明顯變化;無論數(shù)據(jù)是簡單類型還是 C 語言的 struct或 C++ 的類,C 和 C++ 中內(nèi)存管理和引用的模型在原理上都是相同的。以下內(nèi)容絕大部分是“純 C”語言,對于擴(kuò)展到 C++ 主要留作練習(xí)使用。
? 內(nèi)存泄漏
在分配資源時會發(fā)生內(nèi)存泄漏,但是它從不回收。下面是一個可能出錯的模型(請參見清單 1):
void?f1(char?*explanation)
{
??char?p1;
??p1?=?malloc(100);
??sprintf(p1,"The?f1?error?occurred?because?of?'%s'.",explanation);
??local_log(p1);
}
在實際的 C 和 C++ 編程中,這不足以影響您對 malloc()或 new的使用,本部分開頭的句子提到了“資源”不是僅指“內(nèi)存”,因為還有類似以下內(nèi)容的示例(請參見清單 2)。FILE句柄可能與內(nèi)存塊不同,但是必須對它們給予同等關(guān)注:
清單 2. 來自資源錯誤管理的潛在堆內(nèi)存丟失
int?getkey(char?*filename)
{
????FILE?*fp;
????int?key;
????fp?=?fopen(filename,?"r");
????fscanf(fp,?"%d",?&key);
????return?key;
}
? 內(nèi)存錯誤分配
錯誤分配的管理不是很困難。下面是一個示例(請參見清單 3):
清單 3. 未初始化的指針
void?f2(int?datum)
{
???int?*p2;
???/*?Uh-oh!??No?one?has?initialized?p2.?*/
???*p2?=?datum;
???...
}
在此錯誤類型中存在多個變種。free()釋放的內(nèi)存比 malloc()更頻繁(請參見清單 4):
/*?Allocate?once,?free?twice.?*/
void?f3()
{
????char?*p;
????p?=?malloc(10);
?????...
????free(p);
?????...
????free(p);
}
/*?Allocate?zero?times,?free?once.?*/
void?f4()
{
???char?*p;
???/*?Note?that?p?remains?uninitialized?here.?*/
???free(p);
}
懸空指針比較棘手。當(dāng)程序員在內(nèi)存資源釋放后使用資源時會發(fā)生懸空指針(請參見清單 5):
void?f8()
{
???struct?x?*xp;
???xp?=?(struct?x?*)?malloc(sizeof?(struct?x));
???xp.q?=?13;
???...
???free(xp);
???...
/*?Problem!??There's?no?guarantee?that
??the?memory?block?to?which?xp?points
??hasn't?been?overwritten.?*/
??return?xp.q;
}
即使影響提前釋放內(nèi)存范圍的代碼已本地化,內(nèi)存的使用仍然可能取決于應(yīng)用程序甚至(在極端情況下)不同進(jìn)程中的其他執(zhí)行位置。
懸空指針可能發(fā)生在以微妙方式使用內(nèi)存的代碼中。結(jié)果是,即使內(nèi)存在釋放后立即被覆蓋,并且新指向的值不同于預(yù)期值,也很難識別出新值是錯誤值。懸空指針不斷威脅著 C 或 C++ 程序的運行狀態(tài)。
? 數(shù)組邊界違規(guī)
數(shù)組邊界違規(guī)十分危險,它是內(nèi)存錯誤管理的最后一個主要類別?;仡^看一下清單 1;如果 explanation的長度超過 80,則會發(fā)生什么情況?回答:難以預(yù)料,但是它可能與良好情形相差甚遠(yuǎn)。特別是,C 復(fù)制一個字符串,該字符串不適于為它分配的 100 個字符。在任何常規(guī)實現(xiàn)中,“超過的”字符會覆蓋內(nèi)存中的其他數(shù)據(jù)。內(nèi)存中數(shù)據(jù)分配的布局非常復(fù)雜并且難以再現(xiàn),所以任何癥狀都不可能追溯到源代碼級別的具體錯誤。這些錯誤通常會導(dǎo)致數(shù)百萬美元的損失。
? 內(nèi)存編程的策略
勤奮和自律可以讓這些錯誤造成的影響降至最低限度。下面我們介紹一下您可以采用的幾個特定步驟;我在各種組織中處理它們的經(jīng)驗是,至少可以按一定的數(shù)量級持續(xù)減少內(nèi)存錯誤。
? 編碼風(fēng)格
編碼風(fēng)格是最重要的,我還從沒有看到過其他任何作者對此加以強(qiáng)調(diào)。影響資源(特別是內(nèi)存)的函數(shù)和方法需要顯式地解釋本身。下面是有關(guān)標(biāo)頭、注釋或名稱的一些示例(請參見清單 6)。
清單 6. 識別資源的源代碼示例
/********
*?...
*
*?Note?that?any?function?invoking?protected_file_read()
*?assumes?responsibility?eventually?to?fclose()?its
*?return?value,?UNLESS?that?value?is?NULL.
*
********/
FILE?*protected_file_read(char?*filename)
{
????FILE?*fp;
????fp?=?fopen(filename,?"r");
????if?(fp)?{
...
????}?else?{
...
????}
????return?fp;
}
????????/*******
*?...
*
*?Note?that?the?return?value?of?get_message?points?to?a
*?fixed?memory?location.??Do?NOT?free()?it;?remember?to
*?make?a?copy?if?it?must?be?retained?...
*
********/
char?*get_message()
{
????static?char?this_buffer[400];
????????????...
????(void)?sprintf(this_buffer,?...);
????return?this_buffer;
????????}
????????/********
*?...
*?While?this?function?uses?heap?memory,?and?so?
*?temporarily?might?expand?the?over-all?memory
*?footprint,?it?properly?cleans?up?after?itself.
*?
********/
????????int?f6(char?*item1)
{
????my_class?c1;
????int?result;
????????????...
????c1?=?new?my_class(item1);
????...
????????????result?=?c1.x;
????delete?c1;
????return?result;
}
/********
*?...
*?Note?that?f8()?is?documented?to?return?a?value
*?which?needs?to?be?returned?to?heap;?as?f7?thinly
*?wraps?f8,?any?code?which?invokes?f7()?must?be
*?careful?to?free()?the?return?value.
*
********/
int?*f7()
{
????int?*p;
????p?=?f8(...);
????...
????return?p;
}
我沒有做受控實驗來驗證此風(fēng)格的效果。如果您的經(jīng)歷與我一樣,您將發(fā)現(xiàn)沒有說明資源影響的策略簡直無法忍受。這樣做很簡單,但帶來的好處太多了。
檢測是編碼標(biāo)準(zhǔn)的補充。二者各有裨益,但結(jié)合使用效果特別好。機(jī)靈的 C 或 C++ 專業(yè)人員甚至可以瀏覽不熟悉的源代碼,并以極低的成本檢測內(nèi)存問題。通過少量的實踐和適當(dāng)?shù)奈谋舅阉鳎軌蚩焖衮炞C平衡的 *alloc()和 free()或者 new和 delete的源主體。人工查看此類內(nèi)容通常會出現(xiàn)像清單 7中一樣的問題。
清單 7. 棘手的內(nèi)存泄漏
static?char?*important_pointer?=?NULL;
void?f9()
{
if?(!important_pointer)?
important_pointer?=?malloc(IMPORTANT_SIZE);
????????????...
if?(condition)
/*?Ooops!??We?just?lost?the?reference?important_pointer?already?held.?*/
important_pointer?=?malloc(DIFFERENT_SIZE);
????????????...
}
? 靜態(tài)的自動語法分析
當(dāng)然,并不是只有人類才能讀取源代碼。您還應(yīng)使靜態(tài)語法分析成為開發(fā)流程的一部分。靜態(tài)語法分析是 lint、嚴(yán)格編譯和幾種商業(yè)產(chǎn)品執(zhí)行的內(nèi)容:掃描編譯器接受的源文本和目標(biāo)項,但這可能是錯誤的癥狀。
希望讓您的代碼無 lint。盡管 lint已過時,并有一定的局限性,但是,沒有使用它(或其較高級的后代)的許多程序員犯了很大的錯誤。通常情況下,您能夠編寫忽略 lint的優(yōu)秀的專業(yè)質(zhì)量代碼,但努力這樣做的結(jié)果通常會發(fā)生重大錯誤。其中一些錯誤影響內(nèi)存的正確性。與讓客戶首先發(fā)現(xiàn)內(nèi)存錯誤的代價相比,即使對這種類別的產(chǎn)品支付最昂貴的許可費也失去了意義。清除源代碼?,F(xiàn)在,即使 lint標(biāo)記的編碼可能向您提供所需的功能,但很可能存在更簡單的方法,該方法可滿足 lint,并且比較強(qiáng)鍵又可移植。
??內(nèi)存庫
補救方法的最后兩個類別與前三個明顯不同。前者是輕量級的;一個人可以容易地理解并實現(xiàn)它們。另一方面,內(nèi)存庫和工具通常具有較高的許可費用,對部分開發(fā)人員來說,它們需要進(jìn)一步完善和調(diào)整。有效地使用庫和工具的程序員是理解輕量級的靜態(tài)方法的人員??捎玫膸旌凸ぞ呓o人的印象很深:其作為組的質(zhì)量很高。但是,即使最優(yōu)秀的編程人員也可能會被忽略內(nèi)存管理基本原則的非常任性的編程人員攪亂。據(jù)我觀察,普通的編程人員在嘗試?yán)脙?nèi)存庫和工具進(jìn)行隔離工作時也只能感到灰心。
由于這些原因,我們催促 C 和 C++ 程序員為解決內(nèi)存問題先了解一下自己的源。在這完成之后,才去考慮庫。
使用幾個庫能夠編寫常規(guī)的 C 或 C++ 代碼,并保證改進(jìn)內(nèi)存管理。Jonathan Bartlett 在 developerWorks 的 2004 評論專欄中介紹了主要的候選項,可以在下面的參考資料部分獲得。庫可以解決多種不同的內(nèi)存問題,以致于直接對它們進(jìn)行比較是非常困難的;這方面的常見主題包括垃圾收集、智能指針和智能容器。大體上說,庫可以自動進(jìn)行較多的內(nèi)存管理,這樣程序員可以犯更少的錯誤。
我對內(nèi)存庫有各種感受。他們在努力工作,但我看到他們在項目中獲得的成功比預(yù)期要小,尤其在 C 方面。我尚未對這些令人失望的結(jié)果進(jìn)行仔細(xì)分析。例如,業(yè)績應(yīng)該與相應(yīng)的手動內(nèi)存管理一樣好,但是這是一個灰色區(qū)域——尤其在垃圾收集庫處理速度緩慢的情況下。通過這方面的實踐得出的最明確的結(jié)論是,與 C 關(guān)注的代碼組相比,C++ 似乎可以較好地接受智能指針。
??內(nèi)存工具
開發(fā)真正基于 C 的應(yīng)用程序的開發(fā)團(tuán)隊需要運行時內(nèi)存工具作為其開發(fā)策略的一部分。已介紹的技術(shù)很有價值,而且不可或缺。在您親自嘗試使用內(nèi)存工具之前,其質(zhì)量和功能您可能還不了解。
本文主要討論了基于軟件的內(nèi)存工具。還有硬件內(nèi)存調(diào)試器;在非常特殊的情況下(主要是在使用不支持其他工具的專用主機(jī)時)才考慮它們。
市場上的軟件內(nèi)存工具包括專有工具(如 IBM Rational Purify 和 Electric Fence)和其他開放源代碼工具。其中有許多可以很好地與 AIX 和其他操作系統(tǒng)一起使用。
所有內(nèi)存工具的功能基本相同:構(gòu)建可執(zhí)行文件的特定版本(很像在編譯時通過使用 -g標(biāo)記生成的調(diào)試版本)、練習(xí)相關(guān)應(yīng)用程序和研究由工具自動生成的報告。請考慮如清單 8所示的程序。
清單 8. 示例錯誤
int?main()
{
char?p[5];
strcpy(p,?"Hello,?world.");
puts(p);
}
作為一名成熟的 C 或 C++ 程序員,您認(rèn)識到內(nèi)存問題值得特別關(guān)注。通過制訂一些計劃和實踐,可以找到控制內(nèi)存錯誤的方法。學(xué)習(xí)內(nèi)存使用的正確模式,快速發(fā)現(xiàn)可能發(fā)生的錯誤,使本文介紹的技術(shù)成為您日常工作的一部分。您可以在開始時就消除應(yīng)用程序中的癥狀,否則可能要花費數(shù)天或數(shù)周時間來調(diào)試。
版權(quán)申明:內(nèi)容來源網(wǎng)絡(luò),版權(quán)歸原創(chuàng)者所有。除非無法確認(rèn),都會標(biāo)明作者及出處,如有侵權(quán),煩請告知,我們會立即刪除并致歉!
評論
圖片
表情
