MISRA

同一份代码换台电脑检查，告警数量突然变化，可以先核对标准版本、规则包和过滤设置。“MISRA如何核对项目采用的标准版本MISRA检查工具规则版本与项目要求不一致如何校准”，应先查项目约定，再核对工具配置。MISRA是编码指南，下文的工具操作以Perforce QAC英文界面举例。

在嵌入式C代码中，指针加减、数组遍历和缓冲区访问非常常见，但这类写法一旦越过有效对象边界，就可能造成未定义行为或访问错误。MISRA C因此没有把重点放在“能不能使用指针”，而是要求指针运算的目标范围、两个指针之间的关系以及访问边界都能够被明确判断。处理“MISRA C指针运算有哪些限制，MISRA C指针运算违规怎么检查”时，重点应关注Rule 18.1至Rule 18.4，并结合静态分析和代码审查确认指针始终处于合法对象范围。MISRA官方对Rule 18.1的补充说明也进一步明确了指针运算与对象边界之间的关系。

EMTP怎么建立变压器模型EMTP变压器饱和特性怎么设置，在做电力系统暂态仿真时，这两个问题总是绕不过去的。给变压器搭模型这件事，并不是把容量、电压、变比往里一填就算完事了，特别是要分析空载合闸涌流、故障切除、过电压、铁磁谐振这类暂态现象的时候，绕组的阻抗、接线的方式、励磁支路，再加上饱和的那条曲线，全都会把结果给扯向不同的方向。要是模型弄得太粗糙，仿真倒也能吐出一条波形来，可这条波形到底能不能当工程上的参考，就很难讲了。

MISRA遗留问题一直清不动怎么办MISRA老项目分期治理通常怎么切阶段，在不少年头很久的老项目里面，这种事是挺常见的，那些代码都已经稳稳当当地跑了好些年了，功能上也没什么大岔子，可只要把MISRA扫描一接进来，呼啦一下就能扫出几千条甚至上万条的告警，搞开发的一帮人很快就容易没了耐性。到了这种时候，先别急着喊出“全给清到零”的口号，旧代码要是已经有了长长一段跑下来的记录，上手就直接给它来一回大规矩的重构，倒未见得就是最划得来的搞法，这里头打紧的地方是把风险分出层来，把新长出来的问题给拦在门外，再一茬一茬地去对付那些真有危险的老问题。

MISRA偏离流程总被卡住是什么原因MISRA偏离审批最容易缺少哪些依据，很多情况下，问题倒不是出在代码那一头当真就一点不能偏，而是交上去的偏离申请，没能把“为什么非得偏开这一条、偏开以后会冒出哪些险处、这些险处又打算靠什么来按住、最后该由谁来做这个主”给交代得明明白白。在MISRA Compliance:2020里面，对于deviation record和deviation permit这两样东西，是专门有分开来说的，偏离许可能给偏离记录凑上不少材料，可这俩东西是不能随随便便就搅和到一堆去看的。

在嵌入式C软件开发中，函数指针经常用于回调机制、驱动接口抽象以及模块之间的功能切换。相比直接调用固定函数，函数指针能够提高代码灵活性，但也增加了程序执行路径的不确定性。特别是在代码规模较大的控制系统中，如果函数指针初始化不明确、调用前缺少检查，或者指向关系管理混乱，容易造成运行异常。MISRA C针对函数指针使用提出了相关限制，要求开发人员明确函数调用关系，减少隐藏执行路径带来的风险。

在MISRA C项目中，函数返回值是否可以忽略，不能只根据“程序能否正常运行”判断。返回值可能承载执行状态、错误信息或计算结果，如果调用后直接丢弃，很容易把真正的异常处理遗漏隐藏起来。围绕“MISRA C函数返回值可以忽略吗，MISRA C未使用返回值如何合规处理”，需要区分普通返回值、错误状态返回值以及确实经过分析后决定不使用的返回值，再选择对应处理方式。

MISRA代码审查这项工作要怎样去开展，以及审查中发现问题之后要怎样形成闭环，这件事情不能简单地等同于运行一次静态分析工具，再把告警数量降到零。MISRA的合规检查，既包含可以由工具自动识别的编码规则，也包含那些需要结合设计文档和人工判断才能完成的指令要求。一套相对完整的审查过程，应当先把适用的版本、代码覆盖范围和规则等级确定下来，再把工具检查、人工评审、问题修复、偏离审批和回归验证这几项工作串联在一起。如果不是这样，就算工具报告已经显示全部处理完毕，项目仍然可能缺少可以追溯的合规证据。

在动手去模拟线路合闸涌流的时候，要紧的地方不是随便丢一个开关上去，然后就光盯着波形看了，得把线路的那些参量、电源那头是怎么个等值法、合闸到底掐在了什么时刻、线上是不是还挂着没散尽的电压、负荷那头又是怎么个状况，还有量东西的蹲点都给拨弄清爽了才行。线路合闸这档子事，本来就归在典型电磁暂态那堆毛病里头，EMTP这类家伙什常常被拉来跑电力系统的暂态仿真，在开关撂下去的时候，还经常得把合闸那一下子撞在哪个相角上这种没准头的事，也一并兜进来看它带来的结果。

MISRA和AUTOSAR C++14会冲突吗MISRA规则与AUTOSAR规则重叠项该怎么处理，在C++汽车软件项目里头，这类问题一不留神就会冒出来。这两套规则其实全都是在盯着代码的安全程度、可维护程度和可移植程度使劲，它们之间倒不是那种死对头的关系，AUTOSAR C++14 Guidelines本来就是面向C++14的，而且跟MISRA C++:2008之间有一层很清楚的承接关系；后来推出来的MISRA C++:2023呢，又反过来把AUTOSAR C++14里头的不少经验给吸了进去，拿它来对付C++17相关的关键系统开发。所以多数时候，它们看着像是互相拌腿，实际上更可能是同一处风险被两套尺子各量了一回。

嵌入式设备运行时间较长时，内存问题往往不会在程序启动阶段直接暴露。有些程序经过简单测试能够正常运行，但在持续执行任务、频繁处理数据后，可能出现资源不足、任务异常或者系统响应变化。这类问题排查时，开发人员通常需要检查内存申请、释放以及指针使用情况。C语言中的malloc和free虽然能够满足动态数据管理需求，但运行期间的内存变化也会增加程序维护难度。MISRA C针对动态内存使用提出了限制要求，帮助开发人员减少内存泄漏、非法访问以及运行状态不可控等问题。

在普通C程序中，递归本身符合C语言语法，但在MISRA C项目中，是否能用不能只看编译器是否接受。递归会让最大调用深度、栈空间和执行时间更难确定，因此在安全相关和高可靠嵌入式软件中受到严格限制。处理“MISRA C允许使用递归函数吗，MISRA C递归调用违反哪些规则”时，应先明确Rule 17.2的要求，再区分直接递归、间接递归以及正式偏离三种情况。

MISRA规则库的维护以及升级后对历史问题的处理，不能仅仅看作是去工具里面打开一组规则。需要长时间去管理的东西，还有MISRA的版本、工具的版本、规则跟规则之间怎么对应、编译的环境、项目里面做过哪些裁剪、严重等级是如何设定的，还有那些偏离了规则的记录。规则库在升级之后，规则的编号、适用的条件，还有工具具体实现的方式，都是有可能发生变化的，要是直接就拿新的规则去扫描老的代码，历史问题就很容易被重新统计一次，项目质量变化的趋势也就会跟着突然变得不真实。MISRA C:2025现在是MISRA C的现行版本，它是在原来版本的基础上做出来的增量更新，但是合规、偏离还有过程管理这些事情，还是应该按照一个统一的框架来执行。

MISRA偏离记录不是给静态分析工具的告警补一句“确认无风险”，而是针对某一项规则的违背，进行一次正式的论证。记录里面需要说明，为什么这个违背没有办法直接去掉，它会出现在代码的什么位置，可能会带来哪些风险，以及为了控制这些风险，又采取了哪些限制措施和验证手段。只有走完规定的审核和批准流程，这条规则的违背，才能够作为一项受控的偏离被保留下来。

在把MISRA检查接到CI里面之后，噪声太大的问题该怎么处理，门禁阈值在分阶段收紧的时候又该怎样去设置，这些其实是很多嵌入式项目在往前推代码规范的过程中都会碰到的事情。刚把CI接进来那阵子，告警多这件事倒并不奇怪，特别是当历史代码、第三方的库、机器自动生出来的代码，还有平台适配的代码全被一把头扫进去的时候，CI是很容易每一次都挂上红的。在这个阶段里头，不能一上来就催着要把所有的东西都给清到零，可也不能就那么两手一摊什么都不去管了。比较讲得过去的搞法，是头一步先把那一片噪声给拨拉开了，再跟着去把基线楔下去，最末了再分着阶段把门禁给朝紧里勒一勒。

一次MISRA扫描产生上百条告警，开发人员修改后重新扫描，数量确实减少了，但哪些问题已经修好、哪些只是被过滤掉，未必能从汇总数字中看出来。等到版本交付时再补查，往往还要翻提交记录、找旧报告。比较省事的做法，是从发现问题时就保留身份信息，让修改、复查和关闭记录始终围绕同一项问题展开。

嵌入式项目开发过程中，宏定义几乎无法完全避免。硬件寄存器配置、编译选项控制、固定参数管理等场景都会使用宏。不过，宏和普通变量、函数不同，它是在预处理阶段完成替换，代码正式编译前已经改变了原始结构。开发人员看到的宏名称，和编译器最终处理的内容可能并不一致。项目进行MISRA C检查时，一些看似正常的代码，经过宏展开后可能出现类型转换、表达式计算异常等问题。因此，宏使用需要提前规划，出现违规时也需要结合展开结果进行分析。

在嵌入式软件开发中，类型转换属于非常常见的代码行为。变量计算、接口调用、数据存储时，都可能出现不同数据类型之间的转换。C语言为了提高开发灵活性，允许编译器自动完成部分类型转换，但这种自动处理也可能带来一些隐藏问题。例如整数长度变化导致数据丢失，有符号和无符号数据比较出现异常，浮点计算结果产生偏差等。对于汽车电子、控制器软件等长期运行的项目，这类问题通常需要在编码阶段提前发现。MISRA C通过一系列规则限制隐式类型转换，帮助开发人员减少类型使用不明确带来的风险。

switch在状态机、通信协议解析和模式选择中使用频率很高，同时也是MISRA C重点约束的控制结构之一。进行“MISRA C对switch语句有哪些要求，MISRA C switch语句缺少default如何处理”时，应关注分支结构是否清晰、异常输入是否有处理路径，以及整改后是否仍存在控制流隐患。以下主要按照MISRA C:2012的Rule 16.x规则说明。

在TESSY中，测试对象的创建与识别不完整的排查，重点在于让TESSY获得完整的待测源码和编译环境，再通过模块分析将可测试的函数识别出来。当测试对象没有完整显示时，问题通常并不在于测试用例本身，而是源文件的范围、头文件的路径、宏定义、条件编译或者筛选规则，与正式工程没有保持一致。排查时应当先查看分析日志，再去检查预处理之后的源码内容。