我了解 MISRA-C 标准适用于嵌入式固件。当嵌入式 Linux 是您的产品平台时,您的嵌入式应用程序是否可以/应该被开发为符合 MISRA-C 标准?有没有人考虑过这样的练习?
我的一般感觉是,您必须首先了解所有“规则”,然后在您的设计/编码阶段应用它们。可能存在需要强制合规的系统调用 (pthread_create) 和 void* 等实例 - 生成看起来难看的代码。
我了解 MISRA-C 标准适用于嵌入式固件。当嵌入式 Linux 是您的产品平台时,您的嵌入式应用程序是否可以/应该被开发为符合 MISRA-C 标准?有没有人考虑过这样的练习?
我的一般感觉是,您必须首先了解所有“规则”,然后在您的设计/编码阶段应用它们。可能存在需要强制合规的系统调用 (pthread_create) 和 void* 等实例 - 生成看起来难看的代码。
虽然 MISRA-C 最初是作为汽车和安全关键型应用的标准而创建的,但现在已不再适用。如今,MISRA-C 更像是一个通用标准,可用于任何不希望出现错误、崩溃和可移植性问题的 C 程序。
您需要问自己为什么要使用 MISRA-C。是因为您希望将其用作编码标准以消除错误,还是因为该应用程序具有关键任务性质?
对于 Linux 案例,主要问题是您是否只拥有符合 MISRA 的自己的代码,或者您是否要求所有包含的库也是如此。而且你不可能让 Linux 内核 + 库兼容 MISRA,你必须从头开始重写 Linux。
这使得 Linux 不适合任务关键型软件。但是,如果您的程序不是关键任务性质的,您应该能够使用 Linux。您可能需要提前写出一些与 MISRA-C 的长期偏差,因为您可以告诉的事情会导致问题。
一句话:没有。
MISRA 确实提供了一些很好的指导方针,但您最好只遵循您想要遵守的樱桃采摘规则(假设您在构建/静态分析中进行了自动检查)。
浏览 MISRA-2004 的内容,这里有一些问题区域。
让您的所有库都符合 MISRA 本身就是 MISRA 规则。
数十亿行内核和用户空间代码都违反了函数返回和指针运算的规则goto
,所以祝你的库(或内核)合规。continue
break
如果使用套接字以及其他常见 API,则无法遵循指针转换规则。
MISRA-2004 11.2 不应在指向对象的指针和除整数类型、另一个指向对象类型的指针或指向 void 的指针之外的任何类型之间执行转换。
2004-20.x 部分禁止<errno.h>
、<stdio.h>
和. 如果您正在编写长期运行、健壮的服务,那么禁止信号和错误检查会促进糟糕的 Linux 编程。<time.h>
<signal.h>
并且在某处没有动态内存分配是规则。
我知道 MISRA 的规则允许您在记录规则时违反规则(这对于必需的还是只是建议性的???),但是您会记录很多例外情况,这真的是毫无意义的。
综上所述,如果您的客户坚持 MISRA 合规(这是我见过使用它的唯一原因),您可能会记录所有违反规则的行为,并做出一些手动尝试称自己符合 MISRA。因此,在 Linux 上可能存在假装符合 MISRA 的商业案例,但我认为它几乎没有技术优势。
恐怕如果你想真正合规并且需要一个重量级/全功能的操作系统,你最好为 QNX、GHS Integrity、VxWorks 等提供资金。