C語言禍根之看不見的錯誤,那些年學指標從入門到如土都是記憶體問題

標籤：pad   資料庫   soft   https   前言   out   時間   rcv   也會   

是那樣的愛學習

那一刻從入門到入土

醜拒

前言

C 語言程式中的記憶體錯誤非常有害：它們很常見，並且可能導致嚴重的後果，最難受的極大多數時候記憶體問題看不見，也摸不著。編譯正確運行出錯，讓新手從入門到入土，讓老手也頭痛不已，花費很多時間進行尋找和修複。很多時候最嚴重的安全問題都是由簡單的記憶體錯誤造成的，導致軟體崩潰，系統崩潰。與記憶體相關的編程是如此重要，而在實踐中正確應用又是如此困難，以致於它支配著物件導向程式設計語言、功能性程式設計語言、進階程式設計語言、宣告式程式設計語言和另外一些程式設計語言的所有其他變數或理論。因此，出於所有這些原因，需要特別關注 C 的記憶體問題。讓我們看一看如何解決這些問題，先不談是哪種語言。

小編將帶您瞭解一些良好的和記憶體相關的編碼實踐，以將記憶體錯誤保持在控制範圍內。

小編開始裝逼清退後30米

記憶體錯誤分類

所有可能存在的實際問題：

對問題很嚴重，原因卻很簡單

記憶體流失：在分配資源時會發生記憶體流失，但是它從不回收。

小編解析看下面

您看到問題了嗎?除非 Fucntion2對 free釋放的記憶體具有不尋常的響應能力，否則每次對Fucntion1的調用都會泄漏 100 位元組。在記憶棒增量分發數MB記憶體時，一次泄漏是微不足道的，但是連續運算元小時後，即使如此小的泄漏也會削弱應用程式。

小編解析看下面

fopen的語義需要補充性的 fclose。在沒有 fclose的情況下，C 標準不能指定發生的情況時，很可能是記憶體流失。其他資源(如訊號量、網路控制代碼、資料庫連接等)同樣值得考慮。尤其對於C語言檔案操作來說，沒有關閉掉檔案，很容易造成檔案讀寫失敗。

記憶體錯誤分配：指標的初始化

這一點還是很簡單

這些錯誤通常也不太嚴重，稍微對指標概念比較掌握應該是沒什麼問題的。

懸null 指標：野指標（沒有指向的指標）

這種情況尤其在C語言鏈表刪除操作常見

數組邊界違規

數組邊界違規十分危險，它是記憶體錯誤管理的最後一個主要類別。如果一個數組大小事100，超過100，則會發生什麼情況?回答：難以預料，但是它可能與良好情形相差甚遠。特別是，C 複製一個字串，該字串不適於為它分配的 100 個字元。在任何常規實現中，“超過的”字元會覆蓋記憶體中的其他資料。記憶體中資料分配的布局非常複雜並且難以再現，所以任何癥狀都不可能追溯到原始碼層級的具體錯誤。這些錯誤通常會導致數百萬美元的損失。

我有一個公眾號，經常會分享一些C語言/C++技術相關的乾貨；如果你喜歡我的分享，可以用搜尋“C語言學習部落”關注
歡迎大家加入千人交流答疑裙：627+012+464

C語言禍根之看不見的錯誤,那些年學指標從入門到如土都是記憶體問題