原创 带你走近MISRA C:2012

汽车软件与C语言

随着软件定义汽车概念的兴起，汽车软件开发的工作量开始呈指数级增加，当前车载软件代码量已经达到1亿-3亿行。这是一个什么概念呢，相当于比Windows系统还高出一个数量级。据调查，大部分的车载软件都是使用C语言进行开发，因为C执行效率高、代码量小，因此在汽车的小型控制部件中被广泛使用。尽管C语言在嵌入式系统中如此流行，但仍有很多缺陷：

1. C是弱类型语言

 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程序一般不为常见问题提供运行时检查，例如运算异常（如零除），溢出，指针的有效性或者数组越界。

MISRA C编码规范

综上所述，C语言对于安全性要求很高的汽车软件而言是不安全的。汽车工业软件可靠性协会(Motor Industry Software Reliability Association,MISRA)在1998年发布了第一版针对汽车工业软件安全性的C语言编码规范---MISRA C,让程序员有规范可循。

从1998年发布的MISRA C:1998，只针对汽车制造业的嵌入式开发，到MISRA C:2012，已经开始扩大覆盖范围到其他高安全性系统。

下面我们就看一下具体的MISRA C:2012规则内容。

MISRA C:2012规则介绍

MISRA C:2012包含159条规则，其中Directives有16条，Rules有143条。

Dir 4.12:动态内存分配不应被使用。

图1 Dir 4.12规则

原理：任何库的动态内存分配和进程的释放都可能导致未定义的行为。

Rule 10.3:表达式的值不应分配给具有较窄基本类型或不同基本类型类别的对象。

图2 Rule 10.3规则

原理：C语言允许程序员有相当大的自由度，并允许自动形成不同算术类型之间的赋值。然而，使用这些隐式转换可能会导致意外的结果，可能会丢失值、符号或精度。如MISRA基本类型模型所强制的，使用更强的类型可以降低这些问题发生的可能性。

看到这里，相信大家有许多疑问：为什么一个是Dir而另一个是Rule呢？Category、Analysis这些又是什么呢？下面就来介绍一下MISRA规则的分类和属性。

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的分析范围

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 Helix QAC诊断消息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公司的合作伙伴，北汇信息将为客户提供优质的静态代码测试工具和服务。