标签: misra

Perforce 在支持需要稳定和安全的应用程序方面有着悠久的历史。凭借 50 多年的应用程序开发经验，从客户、趋势和竞争对手那里学到了很多东西。 Perforce 从软件开发的所有领域都采用了最佳实践，并试图将这些实践应用于 Perforce 所做的一切。 Perforce 采用了单元测试、自动化测试、敏捷开发、代码审查、持续集成等等。多年来， Perforce 制定了自己的一套内部发展指南，但 Perforce 一直在寻找改进的方法。 像 MISRA® C++ 这样的指南是识别新检查的宝贵资源， Perforce 可以将其应用于代码以继续使其更好。 MISRA ：增强软件安全性和稳定性 MISRA 起源于汽车行业，在汽车行业中保持高标准的软件开发非常重要。 MISRA 提供了一套适用于任何软件应用程序的全面指南，在确保软件安全性和稳定性方面发挥着至关重要的作用。这些准则包含各个方面，例如避免比较运算符右侧的副作用，以及不执行任何指针算术。虽然开发团队通常有自己的代码审查指南，但 MISRA 的附加 规则集 的加入，这些规则已经经过了广泛地研究并证明其可以提高软件质量，代表了在保护软件完整性和可靠性方面的重大飞跃。 实施和执行 MISRA 标准以改进开发实践 理解并同意 MISRA 等标准是提升团队开发实践的重要开始。然而，这些标准的有效性取决于它们的一致应用和测试。 在持续集成 / 持续交付（ CI/CD ）或质量保证（ QA ）流程中集成 Klocwork 等专用工具以检查特定的 MISRA 要求，是确保遵守既定标准的关键手段。此外，这种类型的过程应扩展到应用程序中的任何第三方 C++ 库，例如 ICU 、 OpenSSL 、 DB Client 库、 mat 库等。通过将 MISRA 标准应用于这些库，可以防止应用程序或 C++ 库中出现的漏洞。在整个开发生命周期中强调和实施 MISRA 指南可以显着提高软件的安全性和稳定性。

上接： 一线研发之声 之 C代码注释引发的“血案 (一)       我开始思考，还有什么强劲有力的理由，来支持我恪守的真理：c语言代码注释必须使用/**/. 有的！      倘若所有代码里面的注释用到/**/时，当你要注释掉这段代码时，如果不想忍受编译器的嵌套报警，又懒得把一个个/**/换成//的话。那么你还有如下选择。 1) 慎重 思考下是否删光这段代码，如果还有些不舍，那就先"备份"(git推送)一下再删光。因此， 理由一： 使用/**/注释代码， 会使软件系统减少冗余的僵尸代码，鼓励程序员的程序备份行为。   2) 或者用编译条件圈起来，如下。         #if  (XXX_ENABLE)  func(a, b, c);     /* 注释 */ ......             /* 注释 */ #endif  复制代码     那么你不得不考虑xxx的命名，如何更加一目了然，再写点注释什么的，表明对这段代码“弃而不舍”的缘由。因此， 理由二：使用/**/注释代码，会鼓励程序员删除代码时，三思而后行，并且注明舍弃的理由。   3)  当然，偷懒的人还是会用 #if 0    #endif圈起来， 如下，         #if 0     func(a, b, c);   /* 注释 */ ......           /* 注释 */ #endif 复制代码     而且，不会写任何注释表明删除的理由。然而 ，“#if 0”是一个如此的醒目，很容易成为一个评估软件质量、工作绩效的搜索关键词。 从管理的角度，这个是可以量化的。因此， 理由三:  使用/**/注释代码，有利于公司进行软件质量控管，对程序员绩效考核。   这三个理由，足够为自己代言吗？  

     我要无辜的坦白说，您遇到标题党了。      没有血案，但有些冲突。 不是代码bug，我要讲注释风格。      这位看官，既然来了，且读且评吧。故事是真实的，如有雷同纯属巧合。      事情是这样的，有人离职，公司调我补缺。那个系统一直有个工程师在维护，参与该系统的新人来了又走，他始终泰若磐石。 刚过去一个礼拜，我就心下窃吼：“TMD坑爹啊！”，也彻底体会到什么叫---绝对的 权威、专家。 该软件系统，是公司发家的支柱产品，涉及十几个国家x七八个机型，700+个文件(C语言，所有.c .h档 )，十几万行代码，尽两百个跨模块全局变量，编译条件成百上千......(好吧，这是找借口、吐槽的节奏)      尽管有名义上的交接，和几次和声细语的密切指导。但真正独立展开工作时，许多小功能增删改，我都要折腾个好几天才能厘清代码调用关系、算法原理，然后找到修改点谨慎细微龟速前行。进度追踪的人有的时候也催毛了，直接请专家大师出手，咔咔咔，不到半天就搞定了。当然，前期我当然尽量的”不耻上问”，但人吗，总是有遇到被激发“骨气”的时候。      这几天，好不容易搞好一个全新的功能模块，把代码推送给他合并编译。不曾想，出现了让我泣血的一幕。      我眼睁睁地、眼睁睁看着她把我辛苦敲入的代码注释/**/通通换成//，一份精美的代码，顿时成渣。      我询问缘由，她的回答是: 当代码里面充满注释符号/**/时，她想要用/**/注释整段代码时，就会很麻烦。 我理解了，因为/**/不支持嵌套。比如下面这样的语句是编译不过的。          /*         a = b+c;  /* 注释 */ */ 复制代码      我的手抬了抬，终究作罢。虽然 我感觉到尊严被践踏，心爱的作品被蹂躏，但 我还是开始反思。      许多软件规范、专家、有经验的工程，都建议或要求注释代码最好使用 /**/，他们的理由大略如下: 1.  “//” 的注释的严密性不够。 例如          // 注释语句 ??/   a = b+c; 复制代码   此时，a = b+c在一些编译器不会被执行。   因为"??/"会被编译器当作 \，变成C语言的换行符。于是这段代码等同于             // 注释语句   a = b+c ; 复制代码    就会被注释掉。大家有兴趣的，不妨去搜索一下"C语言  三字母词 "   当然，哪怕没有 ??/ ， 自己打盹碰到delete键也是会屏蔽掉a=b+c的   2. “//” 的注释，是C++发展后才引进的。 有些早期的C编译器对这种注释是不支持的。 代码要做到全平台兼容，这点是必需要考虑的。 因此，老外定义的C语言软件规范，无论是MISRA还是CMMI，一般都要求所有代码注释必须使用/**/。 君不见，那uCOS的最新版本源码，所有注释都是/**/。 君不见，那STM32的最新固件库，洋洋洒洒几十个文件，通篇皆没有用到//。   正是基于这样的理由，让我的心中充满了愠怒。但我仍然没有当场反驳她，因为这些理由还有些苍白无力。 1. 当时，那个什么三字母词“??x”到底是什么我已经忘了，没法立刻做试验编译给她看。 而且时候我里面作了编译实验，得到的是 "filename.c", line xxxx: Warning:  #2532-D: support for trigraphs is disabled xx代码语句xx //  ??/ trigraph金山词霸--- 三字母词 看吧，编译器都警告了，默认是不支持的。 2.  而且，所谓的//是C++的，早期的c编译器不支持。   这点谁鸟啊，我们只要现在，只用最新版本的编译器。   所以，我还要继续思考。 我要维护这个传统，为自己代言...... 下接： 一线研发之声 之 C代码注释引发的“血案” (二)  

As the microprocessors embedded developers become more powerful and the software they design and write gets more complex and increases in size, they are faced with not just increasing opportunities, but also with the need to make the code as safe as is possible to use. This is first being driven by such traditional application segments such as military-aerospace, automotive and medical, which all have strict software certification requirements testing standards in place. The second driver is the uncertain nature of the interactions between these segments with the totally unregulated nature of much of the current consumer and mobile market. And as far as newly burgeoning embedded consumer apps opening up in home electronics, safety does not seem to even be on the radar map. However, according to Mark Pitchford and Bill St. Clair, LDRA, authors of this two-part series , an ever-increasing reliance on software control and the nature of the applications has led many companies to undertake safety-related analysis and testing. " Consider the antilock braking and traction control of today's automobile," they write. "These safety systems are each managed by software running on a networked set of processors; the failure of any of these systems sparks major safety concerns that could lead to recalls and lawsuits. "Companies concerned about safety in their products are looking outside their own market sector for best practice approaches, techniques, and standards. Examples of such industry crossover have been seen in the automotive and avionics industries with the adoption of elements of the DO-178C standard by automotive and a similar adoption of the MISRA standards by avionics." Such crossovers are likely to become more common, placing additional challenges before not only individual developers, but the certification standards groups in various industries as well. In automobile environment, for example, increasing computerisation of not only engine and power train electronics but the infotainment systems, and interactions between them means software safety will be an on-going challenge. And when you add in such things as vehicle-to-vehicle wireless networks, it seems to me that automotive developers have a real can of worms to deal with as far as safety is concerned. In medical designs, for another example, there is an ageing population in many countries where there is considerable effort underway to adapt software and devices originally designed for consumer environments to health and medical applications, forcing standards groups – and the FDA—to go back to the drawing board to come up with specifications and certification requirements that deal with such issues. Fortunately, there are a wide range of tools, RTOS alternatives and requirements and specification testing procedures available. However, despite this range of tools, capabilities and industry specifications to guide developers, there remain considerable uncertainties ahead as embedded systems become more connected and the Internet of Things phenomenon takes hold. Already the auto industry is looking for ways to deal with the intrusion of a variety of mobile smartphones and mobile computing platforms into the automobile and the security issues that raises. Added to that are the moves towards vehicle to vehicle wireless connectivity. Unless there are strict dividing lines between an automobile's entertainment systems, the information systems on which the driver relies and the body/engine electronics, the ultimate safety of any of these sub-systems remains open. In medical applications, the impact of network security on device safety is already raising concerns. Users of medical devices ( such as yours-truly ) who place their lives in the hands of the safety standards the FDA imposes, are continually bombarded on a month by month basis with offers of the newest smartphone app and wireless device add-ons to complement the operation of their medical devices. And the rate at which they are being offered tells me that many of them have not gone though any sort of FDA approval, which traditionally can take years. The dividing line between the methods for developing software for use in a secure environment and for use in a safety-critical design is razor thin. And it is apt to get thinner and more ambiguous unless safety standards organisations also start taking the impact of connectivity and security in how they evaluate safety. To my mind at least, an insecure network-connected device or application by definition is not safe: if you do.  

We often see materials regarding MISRA C/C++ standard. The reason we have continued to focus so much on this standard is that the need for such a disciplined approach is growing more necessary as embedded devices move into areas beyond automotive, military/aerospace and medical equipment to automate more and more aspects of our lives. Beyond the more obvious Roomba robotic vacuum cleaners, numerous aspects of our lives are becoming dependent on automated operation: refrigerators, ovens, microwaves, dishwashers. And much of the "smart grid," which will be supplying electric power to our homes is dependent on the use of more, not less, automation of basic home operations. Also, to make them "safer," and protect them from human error, operation of many common medical devices are being automated. And mobile smart phones are being adapted for such uses with Android and iPhone health apps developed without any thought given to the need for their reliable and safety-critical operation. And since the introduction of MISRA C/C++ for automobiles, the use of microprocessors and microcontrollers there has only increased to the point that fully automated vehicles are already being tested. As a result, the automobile, the focus of the original standard, is even more dependent of safe and reliable firmware and software, not only for use in the drive train and engine electronics, but in applications being developed to aid the driver in operating the vehicle. Given this growing need for safety-critical operation of embedded systems, Jack Ganssle in " MISRA C got bigger and better, " is breathing a sigh of relief with the newest update of the standard. While there are some aspects of the new standard that need even further improvement and others that have him scratching his head, he is generally impressed. " I'm a strong advocate of MISRA, " he writes. " No one (well, with the possible exception of those who crafted the standard) likes all of the rules, but most of them make a lot of sense. MISRA is one way to get a firmware standard in place fast, one that has plenty of street cred. " He points out that one of the things that MISRA has going for it is that there are numerous static analysis tool vendors who have in the past incorporated the standard into their tools. Several companies, including LDRA and PRQA, are already offering upgrades to support the 2012 version of MISRA. However, before you jump into the 2012 version I think it would be a good idea to have a thorough understanding of the benefits and features of the earlier. There is only so far that minding your Ps and Qs during the code development stage will take you. To be completely assured that your application is of the highest quality level and following the safety-critical rules for reliable operation, you will have to be aware of the proper implementation of all aspects of your software design.