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

01

汽車軟件與C語言

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

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有更多操作符及優先級

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

3

C程序一般不為常見問題

提供運行時檢查

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

02

MISRA C編碼規范

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

03

MISRA C:2012規則介紹

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

01

Dir 4.12:動態內存分配不應被使用。

圖1 Dir 4.12規則

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

02

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

圖2 Rule 10.3規則

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

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

04

MISRA C:2012規則分類

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

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

05

Helix QAC與MISRA C:2012

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