作者：給你小魚干小編：吃不飽

01

汽車軟件與C語言

隨著軟件定義汽車概念的興起，汽車軟件開發(fā)的工作量開始呈指數(shù)級增加，當前車載軟件代碼量已經(jīng)達到1億-3億行。這是一個什么概念呢，相當于比Windows系統(tǒng)還高出一個數(shù)量級。據(jù)調查，大部分的車載軟件都是使用C語言進行開發(fā)，因為C執(zhí)行效率高、代碼量小，因此在汽車的小型控制部件中被廣泛使用。盡管C語言在嵌入式系統(tǒng)中如此流行，但仍有很多缺陷：

1

C是弱類型語言

在下面代碼中，char類型和int類型是可以直接運算的，因為char類型會被提升為int，這就是C中的隱式類型轉換，將精度較小的轉換為大精度的，在這個意義上講，它并不符合強類型語言的定義。

#include

int main(void){

char a='a';

int b=10;

int c=a+b;

return 0;

}

2

C有更多操作符及優(yōu)先級

C相較于其他的語言有更多的操作符，因此其也有更多不同的操作符優(yōu)先級，其中的大多數(shù)都不是能直觀判斷的，所以通常會被程序員誤解。

3

C程序一般不為常見問題

提供運行時檢查

C程序一般不為常見問題提供運行時檢查，例如運算異常（如零除），溢出，指針的有效性或者數(shù)組越界。

02

MISRA C編碼規(guī)范

綜上所述，C語言對于安全性要求很高的汽車軟件而言是不安全的。汽車工業(yè)軟件可靠性協(xié)會(Motor Industry Software Reliability Association,MISRA)在1998年發(fā)布了第一版針對汽車工業(yè)軟件安全性的C語言編碼規(guī)范---MISRA C,讓程序員有規(guī)范可循。從1998年發(fā)布的MISRA C:1998，只針對汽車制造業(yè)的嵌入式開發(fā)，到MISRA C:2012，已經(jīng)開始擴大覆蓋范圍到其他高安全性系統(tǒng)。下面我們就看一下具體的MISRA C:2012規(guī)則內容。

03

MISRA C:2012規(guī)則介紹

MISRA C:2012包含159條規(guī)則，其中Directives有16條，Rules有143條。

01

Dir 4.12:動態(tài)內存分配不應被使用。

圖1 Dir 4.12規(guī)則

原理：任何庫的動態(tài)內存分配和進程的釋放都可能導致未定義的行為。

02

Rule 10.3:表達式的值不應分配給具有較窄基本類型或不同基本類型類別的對象。

圖2 Rule 10.3規(guī)則

原理：C語言允許程序員有相當大的自由度，并允許自動形成不同算術類型之間的賦值。然而，使用這些隱式轉換可能會導致意外的結果，可能會丟失值、符號或精度。如MISRA基本類型模型所強制的，使用更強的類型可以降低這些問題發(fā)生的可能性。

看到這里，相信大家有許多疑問：為什么一個是Dir而另一個是Rule呢？Category、Analysis這些又是什么呢？下面就來介紹一下MISRA規(guī)則的分類和屬性。

04

MISRA C:2012規(guī)則分類

MISRA C:2012的規(guī)則按照性質分為兩類：指令（Directives）和規(guī)則（Rules）。規(guī)則有三種不同類別：”強制(Mandatory)”、”要求(Required)”和“建議(Advisory)”；其中具體結果如下圖所示。

圖3 MISRA C:2012規(guī)則分類那么，在任何情況下都可以明確地說明該條代碼違反了規(guī)則嗎？出于此問題，MISRA C:2012規(guī)則的Rules具有可判定性Decidable/Undecidable，他們的區(qū)分標準為是否能在任何情況下明確回答“該代碼是否遵循了這條規(guī)則”？圖4 MISRA C:2012規(guī)則的可判定性要注意的是，可判定性并不適用于Directives規(guī)則。Rules的分析范圍分為Single Translation Unit/System：圖5 Rules的分析范圍

05

Helix QAC與MISRA C:2012

很明顯，MISRA C:2012規(guī)則就是為靜態(tài)測試而生的。Perforce公司的靜態(tài)分析工具Helix QAC，是汽車行業(yè)中主流的靜態(tài)分析器，其開發(fā)團隊是MISRA C&C++編碼委員會的創(chuàng)始會員，也是MISRA C&C++委員會最具影響力的會員。Helix QAC具有業(yè)界領先的編碼規(guī)范覆蓋度，目前MISRA C:2004的編碼規(guī)范覆蓋度達到了99%，而對MISRA C:2012的編碼規(guī)范覆蓋度已達到100%。是嵌入式靜態(tài)分析領域公認的行業(yè)領導及先驅。圖6 Helix QAC的編碼規(guī)范覆蓋度下面以開源工程wget為例，演示一下Helix QAC是如何定位違反MISRA C:2012規(guī)則的代碼。圖7 HelixQAC診斷消息0883診斷消息0883：“包含文件代碼不受重復包含的保護”正是MISRAC:2012規(guī)則Dir 4.10的映射，通過診斷消息開發(fā)人員就可以了解到代碼違反MISRA C:2012規(guī)則的情況，從而對代碼進行修改使其合規(guī)。圖8 Rule 9.1規(guī)則的不同診斷消息Rule 9.1：對象在初始化前不能被使用。圖9 Rule 9.1規(guī)則這里大家或許會疑惑，為什么同一個規(guī)則下會產(chǎn)生兩種診斷消息呢？答案是：數(shù)據(jù)流分析。數(shù)據(jù)流分析是Helix QAC的高級分析，Helix QAC通過內置的數(shù)據(jù)流分析器分析運行時的行為。數(shù)據(jù)流分析可以識別各種問題，包括可能指示編碼錯誤的條件，以及可能導致程序崩潰的關鍵未定義行為。我們可以看到圖中的診斷消息2962和2963雖然都是Rule 9.1產(chǎn)生的，但是分成了Suspicious和Apparent兩種。我們在代碼中看一下這兩條診斷消息的不同。診斷消息2963的源碼如下：
在226行聲明了數(shù)組saved_lengths,241行對saved_lengths進行賦值操作，在255行使用saved_lengths。但saved_lengths的賦值操作不一定會進行，因為該操作在for循環(huán)中進行，如果for循環(huán)沒有達到執(zhí)行條件導致并未執(zhí)行，那么此時saved_lengths就沒有初始化。所以此條診斷消息是Suspicious。診斷消息2962源碼如下：
可以看到，在824行聲明變量dt，但后面并未對dt進行初始化。所以此條診斷消息是Apparent。
由此可見Helix QAC數(shù)據(jù)流分析功能的強大。Helix QAC的數(shù)據(jù)流功能也在不斷地更新，在即將到來的新版本2022.4中，數(shù)據(jù)流計劃從Helix QAC引擎中分離出來，成為自己的組件。在近期發(fā)布的最新版本Helix QAC 2022.3中，引入了對微軟Visual Studio 2022的支持，提供更廣泛的編譯器支持，以及對C++20和C23的升級語言支持。此外，此版本具有使用“qainject”自動生成 CCT 的功能，可簡化構建理解和編譯器設置。作為Perforce公司的合作伙伴，北匯信息將為客戶提供優(yōu)質的靜態(tài)代碼測試工具和服務。