靜態(tài)分析揭示了傳統(tǒng)軟件中的潛在缺陷

靜態(tài)分析工具可以幫助找到并發(fā)性和其他缺陷，以減少遺留的延遲。

從基于軟件的舊系統(tǒng)遷移到新技術(shù)時，能夠重用盡可能多的代碼非常重要。即使這些代碼已經(jīng)過徹底的測試，并且在舊系統(tǒng)中的實(shí)踐中被證明是可靠的，它仍然可能包含潛在的錯誤。這些錯誤可能從未在舊系統(tǒng)中觸發(fā)，因?yàn)樵撓到y(tǒng)非常特定的屬性，例如用于編譯代碼的工具鏈、處理器體系結(jié)構(gòu)或主機(jī)操作系統(tǒng)。當(dāng)移植到這些屬性不同的新系統(tǒng)時，潛在缺陷可能表現(xiàn)為有害錯誤。但好消息是，先進(jìn)的靜態(tài)分析工具可以清除這些潛在的缺陷，以幫助應(yīng)對挑戰(zhàn)。

更新系統(tǒng)，揭示編碼缺陷

遷移遺留系統(tǒng)最重要的動機(jī)之一是利用自原始系統(tǒng)首次部署以來硬件技術(shù)的進(jìn)步。由于采用了更新更快的處理器，最常見的好處可能是性能提高。從代碼的角度來看，這也是一個最重要的變化。新處理器可以具有不同的位寬或字節(jié)序，并且可用內(nèi)核的數(shù)量可以不同。在從舊平臺移植到下一個平臺的代碼期間，大部分重新編碼工作將用于使代碼適應(yīng)這些差異。

編譯器、工具鏈和潛在錯誤

與實(shí)現(xiàn)新處理器相比，還有許多其他不太明顯的差異，這些細(xì)微差別很容易被忽視。以用于編譯代碼的工具鏈為例。從表面上看，這應(yīng)該不會有太大區(qū)別。畢竟，如果代碼是編寫為符合 ANSI C 標(biāo)準(zhǔn)，并且如果編譯器聲稱支持 ANSI C，那么當(dāng)由任一編譯器編譯時，代碼肯定會具有相同的語義嗎？不幸的是不是。C 和 C++ 標(biāo)準(zhǔn)充斥著“編譯器依賴”的子句，這意味著該標(biāo)準(zhǔn)并不確切規(guī)定如何編譯某些結(jié)構(gòu)，選擇取決于編譯器編寫者。其中許多對于程序員來說是顯而易見和眾所周知的，例如計算操作數(shù)的順序，但其他的則非常微妙。潛在錯誤在舊系統(tǒng)上可能是無害的，因?yàn)榫幾g器選擇以特定方式編譯它，但在新系統(tǒng)上是危險的，因?yàn)樾戮幾g器會做出不同的選擇。

當(dāng)然，編譯器也是程序，它們本身并非沒有缺陷。最近一項(xiàng)針對 C 編譯器的研究發(fā)現(xiàn)，他們測試的每個編譯器都有代碼生成缺陷［1］。易失性關(guān)鍵字的處理在嵌入式安全關(guān)鍵型軟件中至關(guān)重要，因?yàn)樗?jīng)常用于讀取傳感器數(shù)據(jù)，特別容易出現(xiàn)編譯器錯誤，從而導(dǎo)致傳感器值的更改被靜默忽略。程序的正確運(yùn)行甚至可能依賴于這些缺陷。

另一個危險區(qū)域：標(biāo)準(zhǔn)庫

另一個可能導(dǎo)致潛在缺陷變得危險的細(xì)微軟件遷移差異涉及與操作系統(tǒng)接口的標(biāo)準(zhǔn)庫。人們可能希望這樣的庫在各個平臺上保持一致，但這種情況很少見。最顯著的區(qū)別是在錯誤處理方面。新平臺可能具有與舊平臺完全不同的故障模式，可能需要更改代碼才能處理這些差異。更糟糕的是，根據(jù)最近的一項(xiàng)研究，錯誤案例的記錄似乎非常糟糕［2］。

靜態(tài)分析勝出，補(bǔ)充傳統(tǒng)測試

顯然，任何遺留遷移項(xiàng)目都必須包括大量時間來測試軟件的新版本。但是，測試結(jié)果僅與測試輸入一樣好。如果測試用例未能執(zhí)行發(fā)生錯誤的路徑，則該缺陷可能無法檢測到。生成新的測試用例也很昂貴。因此，清除這些潛在缺陷的明智策略是使用高級靜態(tài)分析工具作為遺留轉(zhuǎn)換工作的一部分。此類工具能夠發(fā)現(xiàn)本文所述的缺陷，包括那些依賴于平臺微妙之處的缺陷。他們特別擅長發(fā)現(xiàn)并發(fā)缺陷，例如使用傳統(tǒng)測試方法極難發(fā)現(xiàn)的數(shù)據(jù)爭用。他們還擅長查找代碼實(shí)例，這些代碼雖然不是絕對錯誤的，但與錯誤高度相關(guān)，或者在移植到不同環(huán)境時特別危險。

審核編輯：郭婷