什么是MISRA，以及如何烹饪

Perhaps every microcontroller software developer has heard about special coding standards to help improve the code security and portability. One of such standards is MISRA. In this article, we'll take a closer look at what this standard is, its concept and how to use it in your projects.

也许每个微控制器软件开发人员都听说过特殊的编码标准，以帮助提高代码的安全性和可移植性。 MISRA是此类标准之一。 在本文中，我们将仔细研究这个标准是什么，它的概念以及如何在您的项目中使用它。

Many of our readers have heard that PVS-Studio supports the classification of its warnings according to the MISRA standard. At the moment, PVS-Studio covers more than 100 MISRA C rules: 2012 and MISRA C++: 2008.

我们的许多读者都听说PVS-Studio支持根据MISRA标准对其警告进行分类。 目前，PVS-Studio 涵盖了100多个MISRA C规则：2012和MISRA C ++：2008。

This article aims to kill three birds with one stone:

本文旨在用一颗石头杀死三只鸟：

1. Tell what MISRA is for those who aren't yet familiar with this standard;
   告诉MISRA对尚未熟悉此标准的人来说是什么；
2. Remind the world of embedded development what we can do;
   提醒嵌入式开发领域我们能做什么；
3. Help new employees of our company, who will also develop our MISRA analyzer in future, to become fully acquainted with it.
   帮助我们公司的新员工全面熟悉它，他们还将在将来开发我们的MISRA分析仪。

I hope I can make it interesting. So let's get going!

我希望我能使它有趣。 让我们开始吧！

MISRA的历史 (The History of MISRA)

The history of MISRA began a long time ago. Back then in early 1990s, the «Safe IT» UK government program provided funding for various projects somehow related to security of electronic systems. The MISRA (Motor Industry Software Reliability Association) project itself was founded to create a guide for developing software of microcontrollers in ground vehicles — in cars, mostly.

MISRA的历史很久以前就开始了。 早在1990年代初期，“安全IT”英国政府计划就为各种与电子系统安全性相关的项目提供了资金。 MISRA(汽车工业软件可靠性协会)项目本身的创建是为了为开发地面车辆(主要是汽车)中的微控制器软件创建指南。

Having received funding from the state, the MISRA team took up the work, and by November 1994 released their first guide: "Development guidelines for vehicle based software". This guide hasn't been tied to a specific language yet, but I must admit that the work has been done impressively and it has concerned, probably, all conceivable aspects of embedded software development. By the way, recently the developers of this guide have celebrated the 25th anniversary of such an important date for them.

MISRA团队得到了州政府的资助，开始了这项工作，并于1994年11月发布了他们的第一份指南：“ 车载软件开发指南 ”。 该指南尚未与特定语言联系在一起，但是我必须承认，这项工作做得令人印象深刻，并且它涉及嵌入式软件开发的所有可能方面。 顺便说一下，本指南的开发者最近为他们庆祝了这一重要日期的25周年 。

When the funding from the state was over, the MISRA members decided to continue working together on an informal basis, as it continues to this day. Generally speaking, MISRA (as an organization) is a community of stakeholders from various auto and aircraft industries. Now these parties are:

当国家提供的资金结束时，MISRA成员决定继续非正式的合作，直到今天。 一般来说，MISRA(作为一个组织)是来自各个汽车和飞机行业的利益相关者社区。 现在这些聚会是：

• Bentley Motor Cars
  宾利汽车
• Ford Motor Company
  福特汽车公司
• Jaguar Land Rover
  捷豹路虎
• Delphi Diesel Systems
  德尔福柴油系统
• HORIBA MIRA
  ORI场美拉
• Protean Electric
  Protean Electric
• Visteon Engineering Services
  伟世通工程服务
• The University of Leeds
  利兹大学
• Ricardo UK
  英国里卡多
• ZF TRW
  采埃孚TRW

Very strong market players, aren't they? Not surprisingly, their first language-related standard, MISRA C, has become commonplace among developers of critical embedded systems. A little later, MISRA C++ appeared. Gradually, versions of the standards have been updated and refined to cover the new features of languages. As of this writing, the current versions are MISRA C: 2012 and MISRA C++: 2008.

非常强大的市场参与者，不是吗？ 毫不奇怪，他们的第一个与语言相关的标准MISRA C在关键嵌入式系统的开发人员中已变得司空见惯。 不久之后，MISRA C ++出现了。 逐渐地，对标准的版本进行了更新和完善，以涵盖语言的新功能。 撰写本文时，当前版本是MISRA C：2012和MISRA C ++：2008。

规则的主要概念和示例 (Main concept and examples of rules)

MISRA's most distinctive features are its incredible attention to details and extreme meticulousness in ensuring safety and security. Not only did the authors collect all C and C++ deficiencies in one place (as for example, the authors of CERT) — they also carefully worked out the international standards of these languages and wrote out any and all ways to make a mistake. After, they added rules on code readability to insure the clean code against a new error.

MISRA最独特的功能是它对细节的令人难以置信的关注以及在确保安全性和安全性方面的极端细致性。 作者不仅在一个地方收集了所有C和C ++缺陷(例如，CERT的作者)，而且还精心制定了这些语言的国际标准，并写出了所有错误的方法。 之后，他们添加了有关代码可读性的规则，以确保干净的代码不会出现新错误。

To understand the scale of seriousness, let's look at a few rules taken from the standard.

为了了解严重程度，让我们看看从标准中选取的一些规则。

On the one hand, there are decent, worthwhile rules that must always be followed, no matter what your project is for. For the most part, they are designed to eliminate undefined/unspecified/implementation-defined behavior. For example:

一方面，无论您的项目是什么目的，都必须始终遵循体面的有价值的规则。 在大多数情况下，它们旨在消除未定义/未指定/实现定义的行为。 例如：

• Don't use the value of an uninitialized variable
  不要使用未初始化变量的值
• Don't use the pointer to FILE after the stream closes
  流关闭后不要使用指向FILE的指针
• All non-void functions should return a value
  所有非void函数都应返回一个值
• Loop counters mustn't be of the floating-point type
  循环计数器不能为浮点类型
• and others.
  和别的。

On the other hand, there are rules, the benefits of which aren't hard to plumb, but which (from the point of view of ordinary projects) can be occasionally violated:

另一方面，有一些规则，它的好处并不难获得，但是(从普通项目的角度来看)有时会被违反：

• Don't use goto and longjmp
  不要使用goto和longjmp
• Every switch should end with default label
  每个开关应以默认标签结尾
• Don't write unreachable code
  不要编写无法访问的代码
• Don't use variadic functions
  不要使用可变参数函数

• Don't use address arithmetic (except [] and ++)

  不要使用地址算术( []和++除外)

• ...
  ...

Such rules are not bad either, and combined with the previous ones, they already give a tangible increase to security, but is this enough for highly dependable embedded systems? They are used not only in the automotive industry, but also in aviation, aerospace, military and medicine industries.

这样的规则也不错，并且与以前的规则相结合，已经在安全性上带来了明显的提高，但是对于高度可靠的嵌入式系统而言，这是否足够？ 它们不仅用于汽车行业，还用于航空，航天，军事和医药行业。

We don't want any X-ray machine to irradiate patients with a dose of 20,000 rads because of a software error, so the usual «everyday» rules are not enough. With human lives and big money on the line, meticulousness is indispensable. Here's where the rest of MISRA rules come into play:

由于软件错误，我们不希望任何X射线机以20,000拉德的剂量照射患者 ，因此通常的“每天”规则是不够的。 随着人们的生活和巨额资金的流逝，细致是必不可少的。 这是MISRA其余规则起作用的地方：

• The suffix 'L' in the literal must always be capital (the lower case letter 'l' can be confused with 1)
  文字中的后缀“ L”必须始终为大写(小写字母“ l”可以与1混淆)
• Don't use the «comma» operator (it increases the chance of making a mistake)
  不要使用«逗号»运算符(它会增加出错的机会)
• Don't use recursion (a small microcontroller stack can easily overflow)
  不要使用递归(小的微控制器堆栈很容易溢出)

• The bodies of the statements if, else, for, while, do, switch have to be wrapped in curly brackets (potentially you can make a mistake when the code is aligned incorrectly)

  if ， else ， for ， while ， do ， switch的语句主体必须用大括号括起来(当代码未正确对齐时，可能会出错)。

• Don't use dynamic memory (because there's a chance of not releasing it from the heap, especially in microcontrollers)
  不要使用动态内存(因为有可能不从堆中释放它，尤其是在微控制器中)
• … and many, many of these rules.
  ……还有许多其他规则。

It often so happens, that people who first encounter MISRA get the impression that the standard's purpose is to «ban this and ban that». In fact, it is so, but only to some extent.

经常发生这种情况，第一次接触MISRA的人会觉得标准的目的是“禁止并禁止”。 实际上是这样，但仅在一定程度上。

On the one hand, the standard does have many such rules, but it's not meant to ban all out, but on the other hand, it lists the whole schmeer of ways to somehow violate the code security. For most rules, you choose yourself whether you need to follow them or not. I'll explain this case in more detail.

一方面，该标准确实有很多这样的规则，但并不是要禁止所有规则，而另一方面，它列出了某种方式破坏代码安全性的全部方法。 对于大多数规则，您可以选择是否需要遵循它们。 我将详细解释这种情况。

In MISRA C, rules are divided into three main categories: Mandatory, Required and Advisory. Mandatory are rules that cannot be broken under any pretext. For example, this section includes the rule: «don't use the value of an uninitiated variable». Required rules are less stringent: they allow for the possibility of rejection, but only if these deviations are carefully documented and substantiated in writing. The rest of the rules fall into the Advisory category, which are non-obligatory.

在MISRA C中，规则分为三个主要类别：强制性，必需性和咨询性。 强制性规则是不能以任何借口破坏的规则。 例如，此部分包含以下规则：“不要使用未初始化变量的值”。 所需的规则不太严格：它们允许拒绝的可能性，但前提是必须仔细记录并以书面形式证明这些差异。 其余规则属于“咨询”类别，这是非强制性的。

MISRA C++ has some differences: there is no Mandatory category, and most of the rules belong to the Required category. Therefore, in fact, you have the right to break any rule — just don't forget to comment all the deviations. There is also the Document category — these are mandatory rules (deviations aren't allowed) related to general practices such as «Each use of the assembler must be documented» or «An included library must comply with MISRA C++».

MISRA C ++有一些区别：没有强制性类别，并且大多数规则都属于必需类别。 因此，实际上，您有权违反任何规则-只是不要忘了评论所有偏差。 还有“文档”类别-这些是与通用做法相关的强制性规则(不允许偏差)，例如“每次使用汇编程序都必须记录在案”或“所包含的库必须符合MISRA C ++”。

其他事宜 (Other issues)

In fact, MISRA is not just about a set of rules. In fact, it's a guideline for writing safe code for microcontrollers, and so it's full of goodies. Let's take an in-depth look at them.

实际上，MISRA不仅仅是一套规则。 实际上，这是为微控制器编写安全代码的指南，因此充满了好处。 让我们深入研究它们。

First of all, the standard contains a fairly thorough description of the backstory: why the standard was created, why C or C++ was chosen, pros and cons of these languages.

首先，该标准包含对背景知识的相当全面的描述：创建标准的原因，为什么选择C或C ++，这些语言的优缺点。

We all know the merits of these languages very well. As well as we are also aware of their shortcomings :) High level of complexity, incomplete standard specification, and syntax allowing to easily make a mistake and then search for it for ages — all this can't but be mentioned. For example, you might accidentally write this:

我们都非常了解这些语言的优点。 我们也意识到了它们的缺点：)高水平的复杂性，不完整的标准规范和语法使您很容易犯一个错误，然后寻找存在很长时间的错误-所有这些都不得不提及。 例如，您可能不小心将其写为：

for (int i = 0; i < n; ++i);
{
  do_something();
}

After all, there is a chance that a person won't notice an extra semicolon, right? Another option is to write code as follows:

毕竟，人们可能不会注意到多余的分号 ，对吗？ 另一种选择是编写代码，如下所示 ：

void SpendTime(bool doWantToKillPeople)
{
  if (doWantToKillPeople = true)
  {
    StartNuclearWar();
  }
  else
  {
    PlayComputerGames();
  }
}

It's good that both the first and second cases can be easily caught by the rules MISRA (1 — MISRA C: 13.4/MISRA C++: 6.2.1.; 2 — MISRA C: 13.4/MISRA C++: 6.2.1).

很好的是， 第一种情况和第二种情况都可以轻松地被MISRA规则捕获(1 – MISRA C：13.4 / MISRA C ++：6.2.1； 2 – MISRA C：13.4 / MISRA C ++：6.2.1)。

The standard contains both description of problem issues and tips on what one has to know before taking on a certain task: how to set up the development process according to MISRA; how to use static analyzers for checking the code for compliance; what documents one has to maintain, how to fill them out and so on.

该标准既包含对问题的描述，也包括对执行某项任务之前必须了解的知识的提示：如何根据MISRA建立开发流程； 如何使用静态分析器检查代码是否符合要求； 一个人必须维护什么文件，如何填写它们等等。

The appendices at the end also includes: a short list and a summary of the rules, a small list of C/C++ vulnerabilities, an example of a rule deviation documentation, and a few checklists helping to sort out all this bureaucracy.

最后的附录还包括：规则的简短列表和摘要，C / C ++漏洞的小列表，规则偏差文档的示例以及一些有助于整理所有这些官僚机构的清单。

As you can see, MISRA is not just a set of rules, but almost a whole infrastructure for writing secure code for embedded systems.

如您所见，MISRA不仅是一组规则，而且几乎是用于为嵌入式系统编写安全代码的整个基础结构。

在项目中的用法 (Usage in your projects)

Imagine the scene: you're going to write a program for an oh-so-needed and responsible embedded system. Or you already have a program, but you need to «port» it to MISRA. So how do you check your code for its compliance to the standard? Do you really have to do it manually?

想象一下场景：您将为非常需要且负责任的嵌入式系统编写程序。 或者您已经有一个程序，但是您需要将其“移植”到MISRA。 那么，如何检查代码是否符合标准？ 您真的必须手动进行吗？

Manual code verification is an uneasy and even potentially impossible task. Not only does each reviewer have to carefully look through each line of code, but also one has to know the standard nearly by heart. Crazy!

手动代码验证是一项艰巨的任务，甚至可能是不可能完成的任务。 不仅每位审阅者都必须仔细查看每一行代码，而且几乎必须完全了解标准。 疯！

Therefore, the MISRA developers themselves advise using static analysis to test your code. After all, in fact, static analysis is an automated process of code review. You simply run the analyzer on your program and in a few minutes, you get a report of potential violations of the standard. That's what you need, isn't it? All you have to do is review the log and fix the warnings.

因此，MISRA开发人员自己建议使用静态分析来测试您的代码。 毕竟，实际上，静态分析是代码审查的自动化过程。 您只需在程序上运行分析器，几分钟后，您便会收到有关潜在违反标准的报告。 这就是您所需要的，不是吗？ 您所要做的就是查看日志并修复警告。

The next question is — at what point should we start using MISRA? The answer is simple: the sooner the better. Ideally — before you start writing code at all, because MISRA assumes that you follow the standard for the whole of your code's lifecycle.

下一个问题是-我们应该在什么时候开始使用MISRA？ 答案很简单：越快越好。 理想情况下-在您完全开始编写代码之前，因为MISRA假定您在整个代码生命周期中都遵循该标准。

Well it is not always possible to write according to MISRA from the very beginning. For example, it is often the case that the project has already been partially or completely implemented, but later the customer wanted the project to meet the standard. In this case, you will have to deal with a thorough refactoring of the existing code.

嗯，并非一开始就总是可能根据MISRA编写。 例如，通常情况是项目已经部分或完全实施，但是后来客户希望该项目符合标准。 在这种情况下，您将不得不对现有代码进行彻底的重构。

That's where the pitfall pops up. I'd even say an underwater boulder shows up. What happens if you take a static analyzer and check the «ordinary» project to meet the MISRA standard? Spoiler: you may be scared.

那就是陷阱出现的地方。 我什至会说水下巨石出现了。 如果您使用静态分析仪并检查“普通”项目以满足MISRA标准，会发生什么情况？ 剧透：您可能会害怕。

Right, the example in the picture is exaggerated. It shows the result of checking a quite large project that wasn't actually meant for working on microcontrollers. However, when checking already existing code, you might well get one, two, three, or even ten thousand analyzer warnings. New warnings, issued for new or modified code, will simply get lost in this big bunch of warnings.

是的，图中的例子被夸大了。 它显示了检查一个实际上不是用于微控制器的大型项目的结果。 但是，在检查现有代码时，您可能会收到一，二，三甚至一万次分析器警告。 针对新代码或修改后的代码发出的新警告将完全在这些大的警告中丢失。

So what can you do about it? Do you really have to postpone all tasks and go all out on fixing old warnings?

所以你对此能做些什么？ 您真的必须推迟所有任务并全力以赴解决旧警告吗？

As developers of the static analyzer, we know that so many warnings appear after the check. Therefore, we developed the solution, which can help get use from the analyzer right away without stopping the work. This solution is called «suppress base».

作为静态分析器的开发人员，我们知道检查之后会出现很多警告。 因此，我们开发了该解决方案，可以在不停止工作的情况下立即帮助分析仪使用。 此解决方案称为“抑制基础”。

Suppress bases represent the PVS-Studio mechanism that allows you to massively suppress analyzer messages. If you check a project for the first time and get several thousands of warnings — you just need to add them in a suppress base and the next run will give you zero warnings.

抑制基代表PVS-Studio机制，使您可以大量抑制分析器消息。 如果您是第一次检查项目并收到数千条警告，则只需要在抑制基础中添加它们，下一次运行将为您提供零警告。

This way, you can continue to write and change the code as normal, and in doing so, you'll get messages only about bugs that have just been made in the project. So you will get the most benefit from the analyzer right here and now, without being distracted by raking old bugs. A few clicks — and the analyzer is adopted into your development! You can read the detailed instructions about doing this here.

这样，您可以继续照常编写和更改代码，这样做时，您将仅收到有关项目中刚刚发生的错误的消息。 因此，您将在此时此刻从分析器中获得最大的收益，而不会因为耙旧错误而分心。 只需单击几下即可将分析器应用到您的开发中！ 您可以在此处阅读有关此操作的详细说明。

You may probably wonder: «Wait, what about the hidden warnings?» The answer is quite simple: don't forget about them and fix them by easy stages. For example, you can load the suppress base in the version control system and allow only those commits that don't increase the number of warnings. Thus, gradually your «underwater boulder» will sooner or later grind off without leaving a trace.

您可能会想：“等等，隐藏的警告呢？” 答案很简单：不要忘记它们，并通过简单的步骤对其进行修复。 例如，您可以在版本控制系统中加载抑制基，并仅允许那些不会增加警告数量的提交。 因此，逐渐地，您的“水下巨石”将早晚磨掉而不会留下任何痕迹。

Okay, the analyzer is now successfully adopted and we're ready to continue. What to do next? The answer is self-evident — work with the code! But what does it take to be able to declare compliance with the standard? How do you prove that your project complies with MISRA?

好的，分析仪现已成功采用，我们已经准备好继续。 接下来做什么？ 答案不言而喻-使用代码！ 但是，要宣布符合该标准需要做什么？ 您如何证明您的项目符合MISRA？

In fact, there is no special «certificate» that your code corresponds to MISRA. As the standard stipulates, compliance tracking should be done by two parties: the software customer and the software vendor. The vendor develops software that meets the standard and fills out the necessary documents. The customer, in turn, must make sure that the data from these documents is true.

实际上，您的代码没有对应于MISRA的特殊“证明”。 按照标准的规定，合规性跟踪应由两方进行：软件客户和软件供应商。 供应商开发符合标准的软件并填写必要的文档。 反过来，客户必须确保这些文档中的数据是真实的。

If you develop software for yourself, then the responsibility for meeting the standard will lie only on your shoulders :)

如果您自己开发软件，那么达到标准的责任就落在您的肩上:)

In general, to prove the compliance of your project, you will need supporting documents. The list of documents that project developers should prepare may vary, but MISRA offers some set as a reference. Let's take a closer look at this set.

通常，要证明项目的合规性，您将需要证明文件。 项目开发人员应准备的文档清单可能会有所不同，但是MISRA提供了一些文档集作为参考。 让我们仔细看看这个集合。

You'll need these things to apply for the standard compliance:

您将需要这些东西来申请标准合规性：

• The project itself, whose code complies with Mandatory and Required rules
  项目本身，其代码符合强制性和必需规则
• Guide enforcement plan
  指导执行计划
• Documentation on all compiler and static analyzer warnings
  有关所有编译器和静态分析器警告的文档
• Documentation for all deviations from Required Rules
  与要求规则的所有偏离的文档
• Guideline compliance summary
  准则合规摘要

The first is a guide enforcement plan. This is your most important table, and it contains references to all other documents. In its first column is a list of MISRA rules, in the rest, it is noted whether there were any deviations from those rules. This table looks something like this:

首先是指导执行计划。 这是您最重要的表，其中包含对所有其他文档的引用。 在其第一栏中列出了MISRA规则，其余的则指出与这些规则是否有任何差异。 该表如下所示：

The standard recommends building your project with several compilers, as well as use two or more static analyzers to test your code for compliance. If the compiler or analyzer issues a rule-related warning, you should note it in the table and document the following points: why the warning can't be fixed, whether it is false or not, etc.

该标准建议使用多个编译器来构建项目，并使用两个或多个静态分析器来测试代码的符合性。 如果编译器或分析器发出与规则相关的警告，则应在表中记录该警告并记录以下几点：为什么无法修复该警告，该警告是否为假等等。

If one of the rules can't be checked by a static analyzer, you have to perform manual code review. This procedure must also be documented, after which a link to that documentation should be added to the compliance plan.

如果静态分析器无法检查其中一个规则，则必须执行手动代码检查。 还必须记录此过程，然后将指向该文档的链接添加到合规计划中。

If the compiler or static analyzer turns out to be right, or if there are valid rule violations during the code review process, you must either correct them or document them. Again, by attaching the link to the documentation in the table.

如果事实证明编译器或静态分析器是正确的，或者在代码检查过程中存在有效的规则冲突，则必须更正它们或对其进行记录。 同样，通过将链接附加到表中的文档。

Thus, a compliance plan is a document that will provide documentation for any deviation identified in your code.

因此，合规计划是一个文档，它将为您的代码中标识的任何偏差提供文档。

Let's briefly touch on directly documenting deviations from the rules. As I mentioned, such documentation is only necessary for Required Rules, because Mandatory rules cannot be violated, and Advisory rules can be violated without any documentation.

让我们简要介绍一下直接记录与规则的偏差。 正如我提到的，此类文档仅对于必需规则是必需的，因为不能违反强制性规则，并且在没有任何文档的情况下也可能违反咨询规则。

If you choose to deviate from the rule, the documentation should include:

如果您选择偏离规则，则文档应包括：

• The number of the violated rule
  违反规则的数量
• The exact location of the deviation
  偏差的确切位置
• The validity of the deviation
  偏差的有效性
• Proof that the deviation doesn't compromise security
  证明不偏离安全性的证明
• Potential consequences for the user
  对用户的潜在后果

As you can see, such approach to documentation makes you seriously wonder whether the violation is worth it. This was done specifically to feel no desire to violate Required rules :)

如您所见，这种记录文档的方法使您严重怀疑违规是否值得。 这样做是为了不希望违反必需的规则而进行的:)

Now about the summary of compliance with the rules. This paper, perhaps, will be the easiest to fill:

现在介绍遵守规则的摘要。 也许本文将是最容易填写的：

The central column is filled up before you start working with the code, and the right one — after your project is ready.

在开始使用代码之前，中间的列已填充，而在项目准备好之后，右边的列已填充。

Here's a reasonable question: why should the categories of rules be specified, if they are already specified in the standard itself? The fact is that the standard allows «promoting» a rule into a stricter category. For example, a customer might ask you to categorize an Advisory rule. Such a «promotion» should be made before working with the code, and the summary of compliance with the rules allows you to explicitly note it.

这是一个合理的问题：如果在标准本身中已经指定了规则的类别，为什么还要指定规则的类别？ 事实是，该标准允许将规则“推广”到更严格的类别中。 例如，客户可能会要求您对咨询规则进行分类。 应该在使用代码之前进行这种“促销”，并且遵守规则的摘要使您可以明确地注意到它。

As for the last column, it's quite simple: you just need to note whether the rule is being used, and if so, whether there are deviations from it.

至于最后一列，这很简单：您只需要注意是否正在使用该规则，如果正在使用，则是否有偏离。

This whole table is needed so that you can quickly see what priorities rules have and whether the code complies with them. If you're suddenly interested in knowing the exact cause of the deviation, you can always turn to the compliance plan and find the documentation you need.

需要整个表，以便您可以快速查看规则具有哪些优先级以及代码是否符合它们。 如果您突然想知道偏差的确切原因，则可以随时求助于合规计划并找到所需的文档。

So you wrote the code carefully following the MISRA rules. You've made a compliance plan and documented everything that could be documented, and you've filled out your compliance resumes. If this is indeed the case, then you have got a very clean, very readable and very reliable code that you now hate :)

因此，您按照MISRA规则仔细地编写了代码。 您已经制定了合规计划，并记录了可以记录的所有内容，并且填写了合规简历。 如果确实如此，那么您现在已经讨厌了一个非常干净，可读性和可靠性很高的代码：)

Where will your program live now? In an MRI device? In an ordinary speed sensor or in the control system of some space satellite? Yes, you've been through a serious bureaucratic path, but that's no big deal. When it comes to real human lives, you always must be scrupulous.

您的程序现在将放在哪里？ 在MRI设备中？ 在普通的速度传感器中还是在某些太空卫星的控制系统中？ 是的，您已经走过严肃的官僚主义道路，但这没什么大不了的。 在现实生活中，您必须始终谨慎行事。

If you have coped and managed to reach the victorious end, then I sincerely congratulate you: you write high quality safe code. Thank you!

如果您已经成功应对并取得了胜利，那么我衷心地祝贺您：您编写了高质量的安全代码。 谢谢！

标准的未来 (The future of standards)

For the finale, I'd like to dwell on the future of standards.

最后，我想谈谈标准的未来。

Now MISRA lives and evolves. For example, «The MISRA C:2012 Third Edition (First Revision)» is a revised and enlarged with new rules edition announced at the beginning of 2019. At the same time, the upcoming release of «MISRA C: 2012 Amendment 2 – C11 Core», which is a revised standard of the 2012 year, was announced. This document will comprise rules that for the first time cover C language versions of 2011 and 2018 years.

现在，MISRA生活并不断发展。 例如，《 MISRA C：2012第三版(第一次修订)》是经过修订和扩大的，并于2019年初宣布了新的规则版本。与此同时，即将发布的《 MISRA C：2012年修正案2 – C11》宣布了Core»，它是2012年的修订标准。 本文档将包含首次涵盖2011年和2018年C语言版本的规则。

MISRA C++ keeps evolving as well. As you know, the last standard of MISRA C++ is dated 2008, so the oldest version of the language it covers is C++03. Because of this, there is another standard similar to MISRA, and it is called AUTOSAR C++. It was originally intended as a continuation of MISRA C++ and was intended to cover later versions of the language. Unlike its mastermind, AUTOSAR C++ gets updated twice a year and currently supports C++14. New C++17 and then C++20 updates are yet to come.

MISRA C ++也在不断发展。 如您所知，MISRA C ++的最新标准是2008年，所以它涵盖的语言的最早版本是C ++ 03。 因此，还有另一个类似于MISRA的标准，称为AUTOSAR C ++。 它最初旨在作为MISRA C ++的延续，并且旨在涵盖该语言的更高版本。 与它的策划者不同，AUTOSAR C ++每年更新两次，目前支持C ++ 14。 新的C ++ 17和C ++ 20更新尚未到来。

Why did I start talking about some other standard? The fact is that just under a year ago, both organizations announced that they would merge their standards into one. MISRA C++ and AUTOSAR C++ will become a single standard, and from now on they will evolve together. I think that's great news for developers who write for microcontrollers in C++, and no less great news for static analyzer developers. There's a lot more to do! :)

为什么我开始谈论其他标准？ 事实是，不到一年前，这两个组织都宣布将它们的标准合并为一个。 MISRA C ++和AUTOSAR C ++将成为一个单一的标准，从现在开始，它们将一起发展。 对于以C ++编写微控制器的开发人员来说，这是个好消息，对于静态分析器开发人员来说，这也是个好消息。 还有很多事情要做！ :)

结论 (Conclusion)

Today you hopefully learned a lot about MISRA: read the history of its origin, studied the examples of rules and concept of the standard, considered everything you'll need to use MISRA in your projects, and even got a glimpse of the future. I hope now you have a better understanding of what MISRA is and how to cook it!

今天，您希望对MISRA有很多了解：阅读MISRA的历史，研究标准的规则和概念示例，考虑了在项目中使用MISRA所需的一切，甚至还可以窥见到未来。 我希望您现在对MISRA是什么以及如何烹饪有了更好的了解！

In the old tradition, I will leave here a link to our PVS-Studio static analyzer. It is able to find not only deviations from the MISRA standard, but also a huge range of errors and vulnerabilities. If you're interested in trying PVS-Studio yourself, download the demo version and check your project.

在过去的传统中，我将在此处留下指向我们的PVS-Studio静态分析仪的链接。 它不仅可以发现与MISRA标准的偏差，还可以发现大量的错误和漏洞。 如果您想自己尝试使用PVS-Studio，请下载演示版本并检查项目。

That's where my article comes to an end. I wish all readers a merry Christmas and happy New Year's holiday!

那就是我的文章结束的地方。 祝所有读者圣诞快乐，新年快乐！

翻译自: https://habr.com/en/company/pvs-studio/blog/482486/