标签: QAC

随着汽车软件开发的复杂程度不断提升，尤其是智能网联汽车和自动驾驶技术的进步，汽车软件开发的复杂程度不断攀升。为了满足日益增长的功能需求和技术挑战，异构硬件平台被越来越多地采用，不同的工具链也不可避免地被引入到实际的开发流程中。这一趋势不仅增加了开发过程的技术多样性，也使得单个项目的编译过程中会涉及到多种编译器。 本文主要讲解基于静态代码分析工具Helix QAC，我们该如何对多编译器工程进行静态分析。 新版本Helix QAC（2024.1+）的分析方式 为了适应这一趋势，Helix QAC在2024年发布的版本中引入了多CCT的功能。CCT（Compiler Compatibility Template），是Helix QAC软件中存储编译器环境配置的文件。根据CCT文件生成的方式，Helix QAC把CCT分为了两种： 自动CCT（Auto CCT）：在工程同步时，自动生成的CCT； 静态CCT（Static CCT）：基于CCT生产工具提前生成的CCT； 自动CCT 针对自动CCT方式，多编译器的配置也是自动的，无需我们进行额外的设置，目前Helix QAC支持使用自动CCT的编译器如下表： Compiler Filter Command ARM Clang qa_armclang armclang Clang C qa_clang clang,clang- ,clang- ,clang- ,clang- Clang C++ qa_clang clang++,clang++- ,clang++- ,clang++- ,clang++- Compiler caching tools ccache ccache,distcc,ccache-motorola,ccache_cc,ccache_cxx Embarcadero BCC qa_bccclang bcc64 GNU C qa_gnu gcc,cc,c++,gcc- ,gcc- ,gcc- ,gcc- GNU C Cross compilers qa_gnu *-*-gcc,*-*-*-gcc,*-*-*-gcc- * GNU C++ qa_gnu g++,g++- ,g++- ,g++- ,g++- GNU C++ Cross compilers qa_gnu *-*-g++,*-*-*-g++,*-*-*-g++- * GNU cc1/cc1plus qa_gnu_cc1 cc1,cc1plus Green Hills ARM qa_ghs cxarm,ccarm,cxarm64,ccarm64,cxthumb,ccthumb,cxtxarm,cctxarm Green Hills Integrity qa_ghs ccint*,cxint* Green Hills PPC qa_ghs cxppc,ccppc,cxtxppc,cctxppc Green Hills TriCore qa_ghs cctri,cxtri Green Hills v850 qa_ghs cx*850,cc*850,cxv850e,ccv850e Hexagon Clang qa_hexagonclang hexagon-clang,hexagon-clang++ HighTec Tricore qa_hightec tricore-c++,tricore-g++,tricore-gcc IAR compilers qa_icc icc* Keil ArmCC qa_armcc armcc Microchip MPLAB pic24 qa_microchip30 pic30-gcc Microchip MPLAB xc16 qa_microchip16 xc16-gcc Microchip MPLAB xc32 qa_microchip32 xc32-gcc,xc32-g++,xc32-c++ Microchip MPLAB xc8 qa_microchip8 xc8 Microchip MPLAB xc8-cc qa_microchip8cc xc8-cc QNX qa_qnx qcc,QCC,q++ Renesas qa_renesas ccrh,ccrl,ccrx,cx Renesas ca850 qa_renesas_ca850 ca850 Renesas cc78k0 qa_renesas_cc78k0 cc78k0,cc78k0r Synopsys DesignWare ARC qa_metaware ccac TI CCS qa_ti armcl,cl ?*,clpru TI CCS Clang qa_tiarmclang tiarmclang Tasking qa_tasking ctc,cptc,cmcs Visual Studio qa_mscompile cl,clarm,clsh Wind River qa_windriver dplus,dcc 静态CCT 如果我们采用传统的静态CCT的方式，那么需要我们提前为不同的编译器生成对应的CCT文件，并在HeliX QAC中将这些CCT导入到软件中。 Helix QAC现在支持为一种语言选择多个CCT配置，如下： 在我们完成源码加载后，如果不进行单独配置，那么Helix QAC会使用Default CCT对源码进行解析。如果文件夹内的源码使用的编译器与默认CCT不一样，可以在对应的文件属性中重新选择合适的CCT配置。 需要注意的是，我们只能针对文件夹进行CCT的选择，不能针对单个源码进行CCT的配置。而且，对于多CCT的工程，由于这是Helix QAC最新版本才有的功能，因此无法兼容Dashboard，只能将多CCT工程的分析结果上传到Validate中。 老版本Helix QAC的分析方式 由于老版本Helix QAC中无法为文件夹选择不同的CCT，如果要实现多编译器的工程分析，需要借助Helix QAC的CMA工程。 CMA（Cross-Module Analysis），是HeliX QAC提供的一种跨模块分析功能，它允许我们将多个HeliX QAC工程添加到CMA工程中，以进行跨模块的分析，并检查重复定义、不兼容的声明和未使用的变量等问题。 具体到多编译器的工程场景，我们需要为每个编译器建立一个Helix QAC工程，并将使用该编译器的源码及头文件加载到该工程中，然后将这些不同编译器的QAC工程添加到CMA工程中。 显然，Helix QAC的新功能提供了极大便利，来高效支持多编译器。 结语： 通过上述讨论可以看出，随着汽车软件开发复杂度的提升，异构硬件平台的应用已成为必然趋势。多编译器环境的引入不仅是技术发展的自然产物，更是解决日益增长的功能需求和技术挑战的有效途径。在此背景下，Helix QAC 作为一款先进的静态代码分析工具，其新版本中引入的多CCT功能为开发人员提供了强大的支持，该功能不仅简化了多编译器环境下的代码分析过程，还可以极大增强代码的质量和安全性。 如果想试用最新版的Helix QAC，欢迎垂询北汇信息。

随着汽车工业迈入数字化转型的新纪元，软件的安全性与可靠性已跃升为设计和开发核心环节的重中之重。MISRA C++标准的诞生与演进，精准地回应了行业发展的需求。自MISRA C++标准首次面世以来，它便被奉为汽车软件工程师在开发实践中的圭臬。 MISRA C++的发展史 MISRA C++的起源可以追溯到MISRA C标准的成功制定和广泛应用。MISRA C是一套针对C语言的编码规范，首次发布于1998年，它迅速成为汽车行业中软件安全性和可靠性的标杆。（回顾MISRA C:2012介绍请见文章 《带你走近MISRA C:2012》 ）随着C++在工业界的普及，尤其是在汽车电子控制系统中，对C++的类似规范的需求日益增长。基于MISRA C的成功经验和市场需求，MISRA组织随后发布了适用于C++03标准的编码规范MISRA C++:2008。这是首个针对C++语言的MISRA标准，包含一系列的规则和指导原则，这些规则覆盖了从编程实践到代码设计等多个方面，旨在帮助开发者编写出更加安全和可靠的代码。 MISRA C++:2008规范发布后，得到了业界的广泛认可和采纳。它不仅在汽车行业中得到了应用，还扩展到了航空、医疗设备和工业控制等多个领域，并对这些行业产生了深远的影响。随着C++语言标准的不断更新和新特性的引入，MISRA C++:2008也在经历不断的修订和更新，以保持与C++标准语言的同步，并覆盖新出现的语言特性。 MISRA C++:2008与AUTOSAR C++14 但随着后续新版本C++标准的发布，MISRA C++:2008并未将新的C++语言特性纳入，于是AUTOSAR组织发布了AUTOSAR C++14编码规范。 AUTOSAR C++14在制定时，大量借鉴了MISRA C++:2008的规则。MISRA C++:2008是基于C++03标准制定的，而AUTOSAR C++14则是基于更新的C++14标准。AUTOSAR C++14吸收了约91%的MISRA C++:2008规则，并对其进行了扩展和更新，引入了针对C++11/14特性的规范。 MISRA C++:2023 MISRA C++:2023发布于2023年10月，这是MISRA C++的最新版本。它为使用ISO/IEC 14882:2017定义的2017语言版本(C++:17) 开发的安全关键型软件的组织提供指导。 MISRA C++:2023规则分类 MISRA C++:2023整合了AUTOSAR C++14编码规范， 共179条准则。这些规则按照性质分为两类： Rule（规则）和Directive（指令），包含175条Rule和4条Directive。规则有三种不同类别：” Mandatory（强制）”、” Required（要求）”和“Advisory（建议）”， Mandatory类别的规则中包含5条Rule，Required规则中包含122条Rule和4条Directive，Advisory规则中包含48条Rule。 图1 MISRA C++:2023规则分类 图2 MISRA C++:2023规则类别 MISRA C++:2023还引入了MISRA C++的Rule可判定性分类。可判定性区分标准为是否能在任何情况下明确回答“该代码是否遵循了这条规则？”这个问题。 图3 Rule的可判定性分类 要注意的是，可判定性并不适用于Directive规则。 接下来让我们进一步了解MISRA C++:2023编码规范。 什么是 MISRA C++:2023 Rule 9.5.2，为什么它很重要？ MISRA C++:2023 引入了 Rule 9.5.2：“ for 范围初始值设定项最多应包含一个函数调用” ，以避免在基于范围的 for 语句的 for 范围初始值设定项创建临时对象时可能发生的未定义行为。 为了理解为什么会发生这种情况，让我们仔细看看基于 C++ 范围的 for 循环。 什么是 C++ 中基于范围的 for 循环？ 在编程中，循环用于重复代码块。当我们知道要在代码块中循环多少次时会使用for循环。C++ 基于范围的 for 循环是在 C++11 中引入的，作为容器迭代的简洁表示法。传统循环源自 C 语言，具有可选的循环初始化，然后是循环条件，最后是循环增量表达式。 传统for循环可用于迭代容器，如下所示： std::vector v = { "Example", "vector", "of", "strings" }; for ( auto &&i = v.begin(); i != v.end(); ++i ) { std::cout << *i << “ “; } std::cout << std::endl; 使用基于范围的for时，迭代器的使用是隐式的： for ( auto &&s: v ) { std::cout << s << “ “; } 对于同一循环，这是一个更简单的表示法。C++ 语言标准指出它是以下方面的缩写： { auto && __range = v; auto __begin = __range; auto __end = v.end(); for (; __begin != __end; ++__begin) { auto &&s = *__begin; std::cout << s << “ “; } } 但是，这种表示法存在一定的局限性。在上面的示例中， __range 是用 v 初始化的，这是一个更简单的变量，但也可以使用一个复杂的表达式，为其创建多个临时对象。 让我们考虑使用一个函数，该函数返回字符串的向量，并具有： 一个输出用空格分隔的字符串的循环，如上所述; 第二个循环，打印第一个字符串的字母，用空格分隔： std::vector createStrings() { return { "Example”, "vector", "of", "strings" }; } int main() { for ( auto w: createStrings() ) { std::cout << w << " "; } std::cout << std::endl; for ( auto c: createStrings() ) { std::cout << c << " "; } std::cout << std::endl; } 如果我们执行此操作，第一个循环将按预期运行，但第二个循环将调用未定义的行为 。 问题是 createStrings（） 有两个函数调用。最里面的调用是 createStrings 的调用 ，最外面的调用是对索引运算符 的调用。 未定义行为的原因是 “ createStrings ”返回的临时对象 用作“ operator ”调用的参数，因此，根据 C++ 的规则，临时对象的生存期不会延长。 MISRA C++:2023 Rule 9.5.2 如何防范未定义的行为 MISRA C++:2023 Rule 9.5.2 旨在防止这种情况。 MISRA C++:2023 引入了规则 9.5.2，该规则要求for范围初始值设定项最多应包含一个函数调用。 它还建议通过在循环范围之前的单独声明中执行内部函数调用来解决此问题。例如： auto strings = createStrings(); for ( auto c: strings ) { std::cout << c << " "; } 现在，初始值设定项中只有一个函数调用，因此生存期扩展具有所需的效果，并且行为已完全定义。 请注意，此问题已在 C++23 中得到解决，其中初始值设定项的所有临时项的生存期已扩展到整个 for 语句。（原文请参考《 Avoiding Bugs in Range-Based For-Loops with MISRA C++:2023®》 ） 关注更多MISRA C++2023内容请见直播回放《汽车行业为何需要MISRA C++:2023》，本期课程我们联合了嵌入式静态分析领域公认的行业领导及先驱Perforce公司，并邀请到其合规总监Jill Britton女士探讨在这项汽车行业调查中的发现并介绍MISRA C++2023为何如此重要。 使用 Helix QAC 执行 MISRA C++:2023 规则 Perforce 的 Helix QAC 是一款静态分析工具，在提供 MISRA C 和 MISRA C++ 合规性检查以及许多其他有价值的分析功能方面处于领先地位。 Helix QAC 通过其标准合规性模块为 MISRA C++:2023 规则提供 100% 的强制执行覆盖率，现已推出。 作为Perforce公司的合作伙伴，北汇信息将为客户提供优质的静态代码测试工具和服务，欢迎您发邮件到marketing@polelink.com，申请Helix QAC免费试用。

Helix QAC概述 Helix QAC 是一款源码级静态自动化测试工具，主要用于C/C++代码的完全自动化静态分析工作，提供一个高效、健壮和自动化的环境来引入和执行编码标准。Helix QAC根据尽早、更频繁测试的理念，在软件生命周期最早期软件开发阶段应用识别缺陷，提供与功能安全及信息安全密切相关的各类编码规范检测、代码质量度量、软件结构分析、测试结果管理等功能。 Helix QAC能够全面而准确地发现软件中潜在的问题，自身符合ISO26262功能安全标准认证。适用于自动驾驶领域，保障嵌入式软件的质量，提高其防御黑客攻击能力。 Helix QAC主要技术指标如下 · 提供基于行业标准的编程规则对代码进行检测 · 提供对软件的质量分析功能 · 提供对软件结构的分析 · 自动进行工程数据同步 · 提供丰富的CCT库（辅助工程快速配置） · 支持测试报告生成的选项配置，并可实现报告自定制 · 实现团队协作 · 功能安全手册支持静态项目通过各级ASIL（A-D）功能安全认证 Helix QAC产品方案 Helix QAC主要模块为QAC/QAC++（分析组件）、Dashboard(质量管理平台)、以及常用行业规则包（如MISRA C/C++、AUTOSAR C++、CERT C/C++、CWE C/C++等）。 除此之外，还可提供与各行业标准匹配的安全手册（如ISO 26262 Safety Manual等）。 Helix QAC主界面 · Helix QAC分析组件 · Dashboard平台 核心功能 · 多种类、覆盖面广的编程规则 Helix QAC提供与功能安全及信息安全密切相关的各类编码规范检测： Helix QAC对于各类编码规范的映射覆盖情况： 除此之外，Helix QAC还提供基于ISO C/C++标准制定出来的自定制规则集，可实现1900+ C语言问题、1400+ C++语言问题的检测，避免的风险包括但不限于：  未定义的行为  ISO语言约束违反  越界及溢出 (包括除零)  未初始化的数据  内存/指针运算问题（包括空指针引用）  危险的语言使用  不可移植的语言使用  控制流问题  类型转换  冗余代码  移位运算  对象/函数的声明定义问题  标识符的命名规范  违反最佳实践 · 自动对编程规则进行检查 在工具中添加要分析的文件，配置好完相应环境，运行一次就可以对添加的文件进行全部的分析，运行速度快，使用过程非常简单，容易理解，上手很快。 · 非常友好的帮助系统 分析结果内检查错误的时候，如果对所提示的内容不理解，可以双击这个错误，进入帮助系统。帮助系统除了提供了对错误的描述外，大多情况下都提供了例子程序，可以帮助理解错误的原因，并辅助开展代码修正。 · 提供对软件结构的分析 可以分析软件的结构，包括文件之间的包含关系、函数之间的调用关系以及函数自身的结构。 · 提供对软件的质量分析 采用国际标准的软件质量度量方法及度量指标，对客户的代码质量进行评估。提供六十余个指标进行评估，可以方便的在各个指标之间进行切换。 另外，也可以通过警告方式直观显示超阈值门限的指标，并可实时追踪至代码位置。 · 自定制报告 可实现固定模板报告生成，同时也可根据用户需求定制报告内容。可支持导出PDF报告、HTML报告。 · 团队协作 可实现版本管理、基线管理、用户管理、插入注释功能，实现团队协作。 · 可持续集成 支持命令行形式执行分析，能够实现与持续集成环境（如Jenkins等）进行集成。 资质认证证书 应用案例 经纬恒润 可提供服务项 经纬恒润官方账号，了解更多：请拨打010-64840808或发送邮件至 market_dept@hirain.com。联系时请说明，信息来源于面包板社区。

Helix QAC 2022.4 中的新增功能 Helix QAC 2022.4 为 MISRA C:2012 AMD3 提供了 100% 的规则覆盖，数据流被拆分为一个新的组件，提供了改进的分析性能，并升级了对 C++20 和 C23 的语言支持。 此外，此版本还包括改进的编译器支持以及各种 Helix QAC 组件的总体使用质量改进。 数据流组件 在 2022.4 中，数据流已从 QAC/QAC++ 引擎分离到自己的组件中。此更改提供： 1. 改进了大型项目的数据流分析性能。 2. 编译单元间分析 (Inter-TU) 在数据流中内化，不再需要两次分析传递。 3. 头文件中定义的函数每个项目分析一次。 4. 数据流诊断是针对 “ 数据流 ” 组件而不是 “qac” 或 “qacpp” 报告的。 5. 数据流是分析工具链中的一个单独组件，具有自己的配置选项。 编码标准覆盖范围（ MISRA C ： 2012 AMD3 ， TS 17961 C 安全） 新的 MISRA C ： 2012 修正案 3 合规模块，具有 100% 的规则覆盖率 1. 针对 C 编程语言强制实施汽车行业软件可靠性协会 （ MISRA ） 软件开发指南。这些指南旨在促进嵌入式系统环境中的代码功能安全性、信息安全性、可移植性和可靠性。 2. 与新的 C11/C18 功能相关的其他规则。 C++20 语言支持 此版本改进了与 C++20 语言功能用法的兼容性，包括在 C++20 模式下处理 GCC 头文件。 C23 语言支持 此版本增加了对以下各项的 C23 语言功能支持： 放宽对变量参数列表的要求。 改进的编译过程监控 此版本改进了使用 “qainject” 自动生成的 CCT ，这简化了编译理解和编译器设置；并且手册中提供了额外的指导，用于创建自定义过滤器，以基于支持的编译器（例如基于 GNU 的编译器）创建新编译器。 提高使用质量 CLI --添加了查看自基线以来的诊断功能（ qacli 视图）。 --按抑制类型（ qacliview --suppression-filter ）进行过滤诊断。 --以多种格式输出 CMA 诊断： NONE, MULTIPLE, SINGLE （ qacli view --multi-homed-format ）。 --使用户能够升级现有项目以与单独的数据流组件兼容（ qacli admin --upgrade ）。 GUI 数据流组件支持。 Dashboard 数据流组件支持。 Microsoft Visual Studio 2022 IDE 插件 支持使用 VS 2022 扩展安装多个 Helix QAC 。 Helix QAC 2022.4 的重要变化 预公告 CCT Generator 将于 2023 年报废 Helix QAC 2023.1 将不再支持传统的独立 CCT Generator 。 Helix QAC 2021.3 中引入的 “qainject” 工具将取代当前的 CCT Generator 。因此，使用旧版工具生成的 CCT 将被弃用且不再受支持。 从 QAC 软件包中删除不受支持的静态 CCT 随着使用 “qainject” 自动生成 CCT 的各种编译器的改进构建监控，到 2023.1 将删除以前包含在 Helix QAC 包中的大多数静态 CCT 。与使用静态默认 CCT 相比，自动生成的 CCT 有望提供更准确的分析结果。其目的是删除除 GNU gcc 、 Visual Studio 和通用编译器之外的所有 CCT 。

华为的鸿蒙手机操作系统已经发布了几个月了，作为国产操作系统，其寄托了我们的深切希望。 在鸿蒙系统发布会上，手机、平板、智能手表等消费电子类产品固然是主角，而作为华为冉冉升起的新兴业务领域——智能汽车，亦被包含在系统生态之中，也引起了行业的广泛关注。 鸿蒙 作为一个新生的系统，其不可避免的会存在很多问题，而汽车领域对代码的编码规范要求又极为严格。因此本文将通过使用汽车行业主流的静态分析工具，来分析测试鸿蒙系统代码对汽车行业内常用编码规范（CERT、MISRA C 2012、CWEC）的遵循情况。 考虑到标准鸿蒙系统的代码量非常庞大，本文仅以OpenHarmony_1.0.1_release分支中的Hi3861 WLAN模组代码为例进行部分代码的静态测试。 编译鸿蒙系统 Ubuntu 编译环境准备 系统要求：Ubuntu16.04及以上64位系统版本。 本文使用的是搭建在虚拟机中的Ubuntu 18.0系统，编译环境搭建分为如下步骤： ▲获取源码 ▲安装和配置Python ▲安装gn ▲安装ninja ▲安装LLVM ▲ 安装 hb 了解详细的配置步骤请移步鸿蒙开源项目教程指南，本文就不做详细的介绍了，按照文档一步一步进行操作，就可以获取鸿蒙轻量系统源码，并完成编译环境的搭建。 请注意，此时我们还无法编译鸿蒙系统，需要完成后续开发板环境搭建后才能正常编译鸿蒙系统。 Hi3861 开发板环境搭建 为了能正常编译源码中的 wifiiot_hispark_pegasus 工程，我们需要在刚才设置的Ubuntu编译环境中搭建Hi3861开发板环境搭建，如果需要编译别的工程，搭建对应的开发板环境即可。 了解详细的搭建步骤请移步安装Hi3861开发板环境。 编译鸿蒙系统 完成Hi3861开发版环境搭建后，我们就可以正常编译源码中的 wifiiot_hispark_pegasus 工程了，具体步骤如下： ▲到下载的源码根目录下，执行 hb set ，然后会提示让你输入源码根目录，输入当前路径后回车，选择 wifiiot_hispark_pegasus 项目就完成了编译准备工作。 ▲执行hb build即可进行 wifiiot_hispark_pegasus 工程的编译，如果编译结果如下图所示，即表示你成功地编译了该工程。 成功实现 wifiiot_hispark_pegasus 工程的编译后，我们就可以进行后续的静态分析工作了。 鸿蒙系统静态分析 鸿蒙系统编译环境配置 通过编译器环境配置文件生成工具，我们可以很方便地生成鸿蒙编译环境的配置文件，由于wifiiot_hispark_pegasus工程是C工程，因此只配置C编译器的环境即可，考虑到鸿蒙使用的是C99标准，因此需要在生成配置文件时需要添加-std=C99，具体如下图： 然后在静态测试工具中导入该配置文件即可。 静态分析执行 为 了方便后续将鸿蒙的静态分析过程部署到持续集成平台上，本文以命令行的方式进行静态分析操作的演示。具体步骤如下： ▲ 创建QAC工程 ，命令如下： qacli admin --qaf-project-config --qaf-project . --cct "/home/zhou/.config/Perforce/Helix-QAC-2021.1/config/cct/GNU_GCC-riscv32-unknown-elf-gcc_7.3.0-riscv32-unknown-elf-C-c99.cct"--acf"/home/zhou/.config/Perforce/Helix-QAC-2021.1/config/acf/HMOS.acf"--rcf "/home/zhou/.config/Perforce/Helix-QAC-2021.1/config/rcf/HMOS.rcf" 为了更全面地了解鸿蒙系统的代码质量，本文在QAC工程的分析配置文件HMOS.acf中添加了MISRA C 2012合规模块、CERT C合规模块及CWE C合规模块。 ① MISRAC 2012 ：为开发安全关键系统提供编码标准，广泛应用于汽车软件开发。 ② CERT ：信息安全编码标准，能确保您的软件免受潜在的软件安全漏洞的侵害。 ③ CWEC ：常见弱点枚举(CWE)列表标识了软件和硬件中的软件安全弱点。 ▲ 过滤鸿蒙中包含的第三方源码 ，命令如下： qacli pprops -P . --sync-setting FILE_FILTER--set"/home/zhou/Downloads/openHarmony/third_party" 通过该命令，我们可以将鸿蒙工程中包含的第三方源码从QAC工程中过滤出去，这样我们可以更好地通过QAC的分析结果衡量鸿蒙源码的代码质量。 ▲ 将wifiiot_hispark_pegasus工程源码加载到QAC工程中 ，具体命令如下： qacli sync -P . -t MONITOR "cd /home/zhou/Downloads/openHarmony&&hbclean&&hb build" 该命令是通过监测 wifiiot_hispark_pegasus 工程的编译过程，自动将编译过程中调用的源文件和头文件添加到QAC工程中。 ▲ 执行QAC分析 ，具体命令如下： qacli analyze -P . –cf ▲ 生成合规报告 ： qacli report -P . -t RCR ▲ 将分析结果上传到QAC的网页端 ，方便查看，命令如下： qacli upload -P . --qav-upload --upload-project HMOS--snapshot-name v1.0 --upload-source ALL -U https://192.168.9.126:8081/--username admin --password admin 静态分析结果分析 模块 wifiiot_hispark_pegasus 的总体合规情况如下： QAC 共计报出107618条诊断消息，共计违反规则290264次，违反的规则数目为302条（包含MISRA C、CERTC和CWE C），符合的规则有216条，由于模块的文件合规率高达94.19%，但是工程合规率却只有41.70%，所以可以看出违反规则的情况集中在少部分源文件中。 CERT 合规情况 wifiiot_hispark_pegasus 源码的CERT总体违规情况如下图： 图中的图例为CERT C的规则组简写，详细信息如下： 02_DCLDeclarations and Initialization (DCL) 10_ENVEnvironment (ENV) 11_SIGSignals (SIG) 04_INTIntegers (INT) 09_FIOInput Output (FIO) 14_CONConcurrency (CON)08_MEM Memory Management (MEM) 07_STRCharacters and Strings (STR) 03_EXPExpressions (EXP) 违反最多的10条CERT C规则如下图： CERT C规则的违规分布情况如下图： 图中方块面积表示代码量，颜色深浅表示违反CERT的严重程度，由上图可以看出，CERT C的违规情况主要集中在如下源文件中： ▲ cmsis_task_func_test.c：有3182行代码，违反了1951条CERT C的诊断消息； ▲ cmsis_task_pri_func_test.c有1635行代码，违反了1144条CERT C的诊断消息； ▲ tcp_session_manager.c：有1230行代码，违反了912条CERT C的诊断消息； ▲ huks_adapter.c：有1705行代码，违反了862条CERT C的诊断消息； ▲ coap_adapter.c：有638行代码，违反了579条CERT C的诊断消息。 圈复杂度最高的10个函数如下图： 下文我们将摘录部分违反规则的代码进行分析说明： 1. DCL37 Do not declare or define a reserved identifier. (rule) 规则解释： 根据 C 标准，7.1.3 ， 所有以下划线和大写字母或其他下划线开头的所有标识符都始终保留使用。 所有以下划线开头的标识符始终保留，用作普通名称空间和标签名称空间中文件范围的标识符。 违规举例： /HMOS/base/hiviewdfx/hievent_lite/frameworks/hiview_event.c，L28： #define EVENT_VALUE_MAX_NUM 16 此处代码不合规，因为'EVENT_VALUE_MAX_NUM'宏可能在未来与' '中的宏有冲突。 参考ISO:C90Language , ISO:C99 Language 2. INT02 Understand integer conversion rules. (recommend) 规则解释： 转换可以作为强制转换的结果显式发生，也可以根据操作的要求隐式发生。尽管正确执行程序通常需要进行转换，但它们也可能导致数据丢失或被误解。将操作数值转换为兼容类型不会导致值或表示发生变化。 C 整数转换规则定义了 C 编译器如何处理转换。这些规则包括 整数提升 、 整数转换等级 和 通常的算术转换 。规则的意图是确保转化导致相同的数值，并且这些值最小化了其余计算中的意外。Prestandard C 通常更倾向于保留类型的签名。 违规举例 ： /HMOS/base/hiviewdfx/hievent_lite/frameworks/hiview_event.c，L57：e.common.mark = EVENT_INFO_HEAD; 此处代码不合规，因为一个'essentially signed'类型的整型常量在赋值时被转换为'unsigned'类型。 3. DCL23 Guarantee that mutually visible identifiers are unique.(recommend) 规则解释： 根据 C 标准 的第 6.2.7 条， 所有引用同一对象或函数的声明都应具有兼容的类型；否则，行为未定义。 此外，根据第 6.4.2.1 款， 任何在重要字符上不同的标识符都是不同的标识符。如果两个标识符仅在非重要字符上不同，则行为未定义。 违规举例： /HMOS/base/hiviewdfx/hievent_lite/interfaces/native/innerkits/hiview_event.h，L85： void HiEventPutInteger ( HiEvent * event, int8key, uint32 value ) ; 此处代码不合规，因为外部标识符匹配其他外部标识符(例如:'HiEventPrintf')的前6个字符-程序不符合严格的ISO:C90。 参考：ISO:C90 Language ,Security Problems 4. DCL00 Const-qualify immutable objects. (recommend) 规则解释 ： 不可变对象应该使用const限定。使用const限定来强制对象不变性有助于确保应用程序的正确性和安全性。例如，ISO/IEC TR 24772 建议将参数标记为常量，以避免无意中修改函数参数 。STR05-C. Use pointers to const when referringto string literals描述了此建议的特殊情况。 违规举例 ： /HMOS/base/hiviewdfx/hievent_lite/frameworks/hiview_event.c，L50： void HiEventPrintf ( uint8 type,uint16 eventId, int8 key, uint32 value ) 此处代码不合规，因为形参'type'永远不会被修改，因此可以用'const'限定符声明它。 参考：, ISO:C90Language , Security Problems 5. MEM34-C. Only free memory allocated dynamically .(rule) 规则解释： C标准附录J 指出，如下行为是未定义的： free或realloc函数的指针参数与先前由内存管理函数返回的指针不匹配，或者空间已被调用free或realloc释放。 释放非动态分配的内存可能导致堆栈损坏和其他严重错误。不要对非标准内存分配函数返回的指针调用free()，如malloc()、calloc()、realloc()或aligned_alloc()。 违规举例 ： /HMOS/base/security/deviceauth/frameworks/deviceauth_lite/source/struct/parsedata.c，第76行代码： FREE (( char *) payload ) ; 此处代码不合规，因为这是对非动态内存palyload变量的释放，payload定义在/HMOS/base/security/deviceauth/frameworks/deviceauth_lite/source/struct/parsedata.c，L53： payload = json_to_string ( obj_value ) ; 限于篇幅，MISRA C和CWE C的合规情况不在这里一一展示。 结束语 通过对鸿蒙系统部分代码的静态测试，我们尝试了解了鸿蒙系统针对汽车行业常用的代码编程规范的合规情况，期望未来鸿蒙通过不断迭代开发，提升代码的合规程度，进一步改善代码的 质量，成为一个优秀的车载操作系统。