當前位置:首頁 > 公眾號精選 > 嵌入式微處理器
[導讀]本文將帶您了解一些良好的和內存相關的編碼實踐,以將內存錯誤保持在控制范圍內。內存錯誤是 C 和 C++ 編程的禍根:它們很普遍,認識其嚴重性已有二十多年,但始終沒有徹底解決,它們可能嚴重影響應用程序,并且很少有開發(fā)團隊對其制定明確的管理計劃。但好消


本文將帶您了解一些良好的和內存相關的編碼實踐,以將內存錯誤保持在控制范圍內。內存錯誤是 C 和 C++ 編程的禍根:它們很普遍,認識其嚴重性已有二十多年,但始終沒有徹底解決,它們可能嚴重影響應用程序,并且很少有開發(fā)團隊對其制定明確的管理計劃。但好消息是,它們并不怎么神秘。

? 引言

C 和 C++ 程序中的內存錯誤非常有害:它們很常見,并且可能導致嚴重的后果。來自計算機應急響應小組(請參見參考資料)和供應商的許多最嚴重的安全公告都是由簡單的內存錯誤造成的。自從 70 年代末期以來,C 程序員就一直討論此類錯誤,但其影響在至今年仍然很大。更糟的是,如果按我的思路考慮,當今的許多 C 和 C++ 程序員可能都會認為內存錯誤是不可控制而又神秘的頑癥,它們只能糾正,無法預防。

但事實并非如此。本文將讓您在短時間內理解與良好內存相關的編碼的所有本質:

? 正確的內存管理的重要性

存在內存錯誤的 C 和 C++ 程序會導致各種問題。如果它們泄漏內存,則運行速度會逐漸變慢,并最終停止運行;如果覆蓋內存,則會變得非常脆弱,很容易受到惡意用戶的攻擊。從 1988 年著名的莫里斯蠕蟲攻擊到有關 Flash Player 和其他關鍵的零售級程序的最新安全警報都與緩沖區(qū)溢出有關:“大多數(shù)計算機安全漏洞都是緩沖區(qū)溢出”,Rodney Bates 在 2004 年寫道。

在可以使用 C 或 C++ 的地方,也廣泛支持使用其他許多通用語言(如 Java?、Ruby、Haskell、C#、Perl、Smalltalk 等),每種語言都有眾多的愛好者和各自的優(yōu)點。但是,從計算角度來看,每種編程語言優(yōu)于 C 或 C++ 的主要優(yōu)點都與便于內存管理密切相關。與內存相關的編程是如此重要,而在實踐中正確應用又是如此困難,以致于它支配著面向對象編程語言、功能性編程語言、高級編程語言、聲明性編程語言和另外一些編程語言的所有其他變量或理論。

與少數(shù)其他類型的常見錯誤一樣,內存錯誤還是一種隱性危害:它們很難再現(xiàn),癥狀通常不能在相應的源代碼中找到。例如,無論何時何地發(fā)生內存泄漏,都可能表現(xiàn)為應用程序完全無法接受,同時內存泄漏不是顯而易見。

因此,出于所有這些原因,需要特別關注 C 和 C++ 編程的內存問題。讓我們看一看如何解決這些問題,先不談是哪種語言。

? 內存錯誤的類別

首先,不要失去信心。有很多辦法可以對付內存問題。我們先列出所有可能存在的實際問題:

1.內存泄漏
2.錯誤分配,包括大量增加 free()釋放的內存和未初始化的引用
3.懸空指針
4.數(shù)組邊界違規(guī)

這是所有類型。即使遷移到 C++ 面向對象的語言,這些類型也不會有明顯變化;無論數(shù)據(jù)是簡單類型還是 C 語言的 struct或 C++ 的類,C 和 C++ 中內存管理和引用的模型在原理上都是相同的。以下內容絕大部分是“純 C”語言,對于擴展到 C++ 主要留作練習使用。

? 內存泄漏

在分配資源時會發(fā)生內存泄漏,但是它從不回收。下面是一個可能出錯的模型(請參見清單 1):

清單 1. 簡單的潛在堆內存丟失和緩沖區(qū)覆蓋


以下是引用片段:
void f1(char *explanation){ char p1;
p1 = malloc(100); (void) sprintf(p1, "The f1 error occurred because of '%s'.", explanation); local_log(p1);}

您看到問題了嗎?除非 local_log()對 free()釋放的內存具有不尋常的響應能力,否則每次對 f1的調用都會泄漏 100 字節(jié)。在記憶棒增量分發(fā)數(shù)兆字節(jié)內存時,一次泄漏是微不足道的,但是連續(xù)操作數(shù)小時后,即使如此小的泄漏也會削弱應用程序。

在實際的 C 和 C++ 編程中,這不足以影響您對 malloc()或 new的使用,本部分開頭的句子提到了“資源”不是僅指“內存”,因為還有類似以下內容的示例(請參見清單 2)。FILE句柄可能與內存塊不同,但是必須對它們給予同等關注:

清單 2. 來自資源錯誤管理的潛在堆內存丟失
 
以下是引用片段:

int getkey(char *filename){ FILE *fp; int key;
fp = fopen(filename, "r"); fscanf(fp, "%d", &key); return key; }

fopen的語義需要補充性的 fclose。在沒有 fclose()的情況下,C 標準不能指定發(fā)生的情況時,很可能是內存泄漏。其他資源(如信號量、網(wǎng)絡句柄、數(shù)據(jù)庫連接等)同樣值得考慮。

? 內存錯誤分配

錯誤分配的管理不是很困難。下面是一個示例(請參見清單 3):

清單 3. 未初始化的指針
 
以下是引用片段:

void f2(int datum){ int *p2;
/* Uh-oh! No one has initialized p2. */ *p2 = datum; ...        }

關于此類錯誤的好消息是,它們一般具有顯著結果。在 AIX 下,對未初始化指針的分配通常會立即導致 segmentation fault錯誤。它的好處是任何此類錯誤都會被快速地檢測到;與花費數(shù)月時間才能確定且難以再現(xiàn)的錯誤相比,檢測此類錯誤的代價要小得多。

在此錯誤類型中存在多個變種。free()釋放的內存比 malloc()更頻繁(請參見清單 4):

清單 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);}


這些錯誤通常也不太嚴重。盡管 C 標準在這些情形中沒有定義具體行為,但典型的實現(xiàn)將忽略錯誤,或者快速而明確地對它們進行標記;總之,這些都是安全情形。

? 懸空指針

懸空指針比較棘手。當程序員在內存資源釋放后使用資源時會發(fā)生懸空指針(請參見清單 5):

清單 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; }


傳統(tǒng)的“調試”難以隔離懸空指針。由于下面兩個明顯原因,它們很難再現(xiàn):

即使影響提前釋放內存范圍的代碼已本地化,內存的使用仍然可能取決于應用程序甚至(在極端情況下)不同進程中的其他執(zhí)行位置。

懸空指針可能發(fā)生在以微妙方式使用內存的代碼中。結果是,即使內存在釋放后立即被覆蓋,并且新指向的值不同于預期值,也很難識別出新值是錯誤值。懸空指針不斷威脅著 C 或 C++ 程序的運行狀態(tài)。

? 數(shù)組邊界違規(guī)

數(shù)組邊界違規(guī)十分危險,它是內存錯誤管理的最后一個主要類別?;仡^看一下清單 1;如果 explanation的長度超過 80,則會發(fā)生什么情況?回答:難以預料,但是它可能與良好情形相差甚遠。特別是,C 復制一個字符串,該字符串不適于為它分配的 100 個字符。在任何常規(guī)實現(xiàn)中,“超過的”字符會覆蓋內存中的其他數(shù)據(jù)。內存中數(shù)據(jù)分配的布局非常復雜并且難以再現(xiàn),所以任何癥狀都不可能追溯到源代碼級別的具體錯誤。這些錯誤通常會導致數(shù)百萬美元的損失。

? 內存編程的策略

勤奮和自律可以讓這些錯誤造成的影響降至最低限度。下面我們介紹一下您可以采用的幾個特定步驟;我在各種組織中處理它們的經(jīng)驗是,至少可以按一定的數(shù)量級持續(xù)減少內存錯誤。

? 編碼風格

編碼風格是最重要的,我還從沒有看到過其他任何作者對此加以強調。影響資源(特別是內存)的函數(shù)和方法需要顯式地解釋本身。下面是有關標頭、注釋或名稱的一些示例(請參見清單 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;}

使這些格式元素成為您日常工作的一部分??梢允褂酶鞣N方法解決內存問題:

專用庫
語言
軟件工具

硬件檢查器在這整個領域中,我始終認為最有用并且投資回報率最大的是考慮改進源代碼的風格。它不需要昂貴的代價或嚴格的形式;可以始終取消與內存無關的段的注釋,但影響內存的定義當然需要顯式注釋。添加幾個簡單的單詞可使內存結果更清楚,并且內存編程會得到改進。

我沒有做受控實驗來驗證此風格的效果。如果您的經(jīng)歷與我一樣,您將發(fā)現(xiàn)沒有說明資源影響的策略簡直無法忍受。這樣做很簡單,但帶來的好處太多了。

? 檢測

檢測是編碼標準的補充。二者各有裨益,但結合使用效果特別好。機靈的 C 或 C++ 專業(yè)人員甚至可以瀏覽不熟悉的源代碼,并以極低的成本檢測內存問題。通過少量的實踐和適當?shù)奈谋舅阉鳎軌蚩焖衮炞C平衡的 *alloc()和 free()或者 new和 delete的源主體。人工查看此類內容通常會出現(xiàn)像清單 7中一樣的問題。

清單 7. 棘手的內存泄漏
 
以下是引用片段:

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); ...        }

如果 condition為真,簡單使用自動運行時工具不能檢測發(fā)生的內存泄漏。仔細進行源分析可以從此類條件推理出證實正確的結論。我重復一下我寫的關于風格的內容:盡管大量發(fā)布的內存問題描述都強調工具和語言,對于我來說,最大的收獲來自“軟的”以開發(fā)人員為中心的流程變更。您在風格和檢測上所做的任何改進都可以幫助您理解由自動化工具產(chǎn)生的診斷。

? 靜態(tài)的自動語法分析

當然,并不是只有人類才能讀取源代碼。您還應使靜態(tài)語法分析成為開發(fā)流程的一部分。靜態(tài)語法分析是 lint、嚴格編譯和幾種商業(yè)產(chǎn)品執(zhí)行的內容:掃描編譯器接受的源文本和目標項,但這可能是錯誤的癥狀。

希望讓您的代碼無 lint。盡管 lint已過時,并有一定的局限性,但是,沒有使用它(或其較高級的后代)的許多程序員犯了很大的錯誤。通常情況下,您能夠編寫忽略 lint的優(yōu)秀的專業(yè)質量代碼,但努力這樣做的結果通常會發(fā)生重大錯誤。其中一些錯誤影響內存的正確性。與讓客戶首先發(fā)現(xiàn)內存錯誤的代價相比,即使對這種類別的產(chǎn)品支付最昂貴的許可費也失去了意義。清除源代碼?,F(xiàn)在,即使 lint標記的編碼可能向您提供所需的功能,但很可能存在更簡單的方法,該方法可滿足 lint,并且比較強鍵又可移植。

?
內存庫

補救方法的最后兩個類別與前三個明顯不同。前者是輕量級的;一個人可以容易地理解并實現(xiàn)它們。另一方面,內存庫和工具通常具有較高的許可費用,對部分開發(fā)人員來說,它們需要進一步完善和調整。有效地使用庫和工具的程序員是理解輕量級的靜態(tài)方法的人員。可用的庫和工具給人的印象很深:其作為組的質量很高。但是,即使最優(yōu)秀的編程人員也可能會被忽略內存管理基本原則的非常任性的編程人員攪亂。據(jù)我觀察,普通的編程人員在嘗試利用內存庫和工具進行隔離工作時也只能感到灰心。

由于這些原因,我們催促 C 和 C++ 程序員為解決內存問題先了解一下自己的源。在這完成之后,才去考慮庫。

使用幾個庫能夠編寫常規(guī)的 C 或 C++ 代碼,并保證改進內存管理。Jonathan Bartlett 在 developerWorks 的 2004 評論專欄中介紹了主要的候選項,可以在下面的參考資料部分獲得。庫可以解決多種不同的內存問題,以致于直接對它們進行比較是非常困難的;這方面的常見主題包括垃圾收集、智能指針和智能容器。大體上說,庫可以自動進行較多的內存管理,這樣程序員可以犯更少的錯誤。

我對內存庫有各種感受。他們在努力工作,但我看到他們在項目中獲得的成功比預期要小,尤其在 C 方面。我尚未對這些令人失望的結果進行仔細分析。例如,業(yè)績應該與相應的手動內存管理一樣好,但是這是一個灰色區(qū)域——尤其在垃圾收集庫處理速度緩慢的情況下。通過這方面的實踐得出的最明確的結論是,與 C 關注的代碼組相比,C++ 似乎可以較好地接受智能指針。

?
內存工具

開發(fā)真正基于 C 的應用程序的開發(fā)團隊需要運行時內存工具作為其開發(fā)策略的一部分。已介紹的技術很有價值,而且不可或缺。在您親自嘗試使用內存工具之前,其質量和功能您可能還不了解。

本文主要討論了基于軟件的內存工具。還有硬件內存調試器;在非常特殊的情況下(主要是在使用不支持其他工具的專用主機時)才考慮它們。

市場上的軟件內存工具包括專有工具(如 IBM Rational Purify 和 Electric Fence)和其他開放源代碼工具。其中有許多可以很好地與 AIX 和其他操作系統(tǒng)一起使用。

所有內存工具的功能基本相同:構建可執(zhí)行文件的特定版本(很像在編譯時通過使用 -g標記生成的調試版本)、練習相關應用程序和研究由工具自動生成的報告。請考慮如清單 8所示的程序。

清單 8. 示例錯誤
 
以下是引用片段:

int main(){ char p[5]; strcpy(p, "Hello, world."); puts(p);}

此程序可以在許多環(huán)境中“運行”,它編譯、執(zhí)行并將“Hello, world.n”打印到屏幕。使用內存工具運行相同應用程序會在第四行產(chǎn)生一個數(shù)組邊界違規(guī)的報告。在了解軟件錯誤(將十四個字符復制到了只能容納五個字符的空間中)方面,這種方法比在客戶處查找錯誤癥狀的花費小得多。這是內存工具的功勞。

? 結束語

作為一名成熟的 C 或 C++ 程序員,您認識到內存問題值得特別關注。通過制訂一些計劃和實踐,可以找到控制內存錯誤的方法。學習內存使用的正確模式,快速發(fā)現(xiàn)可能發(fā)生的錯誤,使本文介紹的技術成為您日常工作的一部分。您可以在開始時就消除應用程序中的癥狀,否則可能要花費數(shù)天或數(shù)周時間來調試。

-END-




推薦閱讀



【01】各路大牛的C語言編程建議和技巧,看完感觸頗深
【02】C語言驗證大小端的幾個方法
【03】TIOBE 5月 C 語言回歸王座,聽聽嵌入式er怎么看待語言這件事兒
【04】嵌入式工程師,別怪"浮點數(shù)"太坑?。–語言版本)
【05】C語言寫個貪吃蛇游戲



免責聲明:整理文章為傳播相關技術,版權歸原作者所有,如有侵權,請聯(lián)系刪除

免責聲明:本文內容由21ic獲得授權后發(fā)布,版權歸原作者所有,本平臺僅提供信息存儲服務。文章僅代表作者個人觀點,不代表本平臺立場,如有問題,請聯(lián)系我們,謝謝!

嵌入式ARM

掃描二維碼,關注更多精彩內容

本站聲明: 本文章由作者或相關機構授權發(fā)布,目的在于傳遞更多信息,并不代表本站贊同其觀點,本站亦不保證或承諾內容真實性等。需要轉載請聯(lián)系該專欄作者,如若文章內容侵犯您的權益,請及時聯(lián)系本站刪除。
換一批
延伸閱讀

9月2日消息,不造車的華為或將催生出更大的獨角獸公司,隨著阿維塔和賽力斯的入局,華為引望愈發(fā)顯得引人矚目。

關鍵字: 阿維塔 塞力斯 華為

加利福尼亞州圣克拉拉縣2024年8月30日 /美通社/ -- 數(shù)字化轉型技術解決方案公司Trianz今天宣布,該公司與Amazon Web Services (AWS)簽訂了...

關鍵字: AWS AN BSP 數(shù)字化

倫敦2024年8月29日 /美通社/ -- 英國汽車技術公司SODA.Auto推出其旗艦產(chǎn)品SODA V,這是全球首款涵蓋汽車工程師從創(chuàng)意到認證的所有需求的工具,可用于創(chuàng)建軟件定義汽車。 SODA V工具的開發(fā)耗時1.5...

關鍵字: 汽車 人工智能 智能驅動 BSP

北京2024年8月28日 /美通社/ -- 越來越多用戶希望企業(yè)業(yè)務能7×24不間斷運行,同時企業(yè)卻面臨越來越多業(yè)務中斷的風險,如企業(yè)系統(tǒng)復雜性的增加,頻繁的功能更新和發(fā)布等。如何確保業(yè)務連續(xù)性,提升韌性,成...

關鍵字: 亞馬遜 解密 控制平面 BSP

8月30日消息,據(jù)媒體報道,騰訊和網(wǎng)易近期正在縮減他們對日本游戲市場的投資。

關鍵字: 騰訊 編碼器 CPU

8月28日消息,今天上午,2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會開幕式在貴陽舉行,華為董事、質量流程IT總裁陶景文發(fā)表了演講。

關鍵字: 華為 12nm EDA 半導體

8月28日消息,在2024中國國際大數(shù)據(jù)產(chǎn)業(yè)博覽會上,華為常務董事、華為云CEO張平安發(fā)表演講稱,數(shù)字世界的話語權最終是由生態(tài)的繁榮決定的。

關鍵字: 華為 12nm 手機 衛(wèi)星通信

要點: 有效應對環(huán)境變化,經(jīng)營業(yè)績穩(wěn)中有升 落實提質增效舉措,毛利潤率延續(xù)升勢 戰(zhàn)略布局成效顯著,戰(zhàn)新業(yè)務引領增長 以科技創(chuàng)新為引領,提升企業(yè)核心競爭力 堅持高質量發(fā)展策略,塑強核心競爭優(yōu)勢...

關鍵字: 通信 BSP 電信運營商 數(shù)字經(jīng)濟

北京2024年8月27日 /美通社/ -- 8月21日,由中央廣播電視總臺與中國電影電視技術學會聯(lián)合牽頭組建的NVI技術創(chuàng)新聯(lián)盟在BIRTV2024超高清全產(chǎn)業(yè)鏈發(fā)展研討會上宣布正式成立。 活動現(xiàn)場 NVI技術創(chuàng)新聯(lián)...

關鍵字: VI 傳輸協(xié)議 音頻 BSP

北京2024年8月27日 /美通社/ -- 在8月23日舉辦的2024年長三角生態(tài)綠色一體化發(fā)展示范區(qū)聯(lián)合招商會上,軟通動力信息技術(集團)股份有限公司(以下簡稱"軟通動力")與長三角投資(上海)有限...

關鍵字: BSP 信息技術
關閉
關閉