MISRA C 2004****规范解读1
Grey
全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!
MISRA C 2004规范解读
开篇
其实，这个是一个很基础的只是体系了。但是，现在我自己在工作中用到的其实不多。主要是现在接触到的工程师水平参差不齐，加上各种各样的因素，导致大家都很忙，唯独没有时间看看这样的保险防护的技能。最近很长一段时间里，我自己的工作性质多少转向了管理协调类为主，但是回看我个人的整个职业生涯，我的角色其实还是一个工程师。而平静下心思来思考，我真正喜欢的似乎还是利用各种技术完成设计创造。于此同时，我也喜欢弄清楚如何做以及怎么做会让我们更好。既然工作时间不够，那么就个人时间来凑了。这个体系一共一百多条规则，即使是我能够一条条梳理出来然后在工作之中指点一般工程师应用遵循，我觉得应该也是很有价值的。以此，为我新的学习目标做一个开篇。开始终究是开始了，但是究竟能够花多少时间坚持多久？我自己现在也是满脑子的问号，毕竟，这不该是我生活的全部。
摘录以及批注
- MISRA C的目标其实还是很明确的，就是汽车电子安全性领域的辅助。
- 在嵌入式方面，促成一个最佳实践方案。
- 从描述看，其实这个规则推行的领域还是很多的，不仅仅是在汽车电子领域。
- 本身规则的推行与现有的MCU平台以及工具链也有一定的关系，考虑到了相应的适用性。
- 规则条目其实不多，122条强制，20条推荐。
- 规范会升级，我看的其实也不是最新的版本。但是我觉得大多数的内容还是有参考意义的，毕竟我自己原本的设想也不是要毕其功于一役搞定。就按照这个版本一点点慢慢来。
- 其实这里没有什么特别的技术信息，但是我看到了一个熟悉的HIS。之前只是在BootLoader等类似的要求中看过，知道这个也是奔驰采用的，现在才知道具体的缩写含义。不过，这个名字太难记了，估计以后我也就只记得住一个HIS。
错误产生的原因很多，也涉及到很多方面，几条在工作中遇到的做一个摘录：
人为性错误，比如说直接输入错误或者理解错误。
编码的风格以及表现力问题，可能会导致合作上很大的偏差。
语言本身在错误发生时做不到自检处理。
语言设计本身在语法等方面有一些固有的缺陷。
- 程序员对于语言的表达有错误的认识，诸如优先级等方面，会导致一些错误的产生。
- C语言本身有一些未定义的行为，而这些在不同的编译器中实现不同，可能恰好跟程序员的想法不同。
- 编译器也是软件，也不一定百分百靠得住。
- C语言运行时检查做的非常差，这是其简单高效的原因，但是也带来了很多风险。
- 静态检查可以避免掉一些运行时等问题。
- C语言有很多安全上的风险点，但是并不是说其他语言就一定好，汇编有时候更差。
- C标准也在更新当中，但是比较新的可能就会有工具支持滞后这样的问题。
- 文档本身也不是百分百正确，有勘误更新。
未来的计划想法
这一次，针对这个规范做了一个了起步性的了解，还没有任何可以让我值得推广实施的经验总结下来。也不用着急于一时，只要有了这个计划表并且抽时间不断前进，一切总归还是会向越来越好的方向发展。
标签：
MISRA C
本文转载自: https://blog.csdn.net/grey_csdn/article/details/122292084
版权归原作者 grey_csdn 所有， 如有侵权，请联系我们删除。
版权归原作者 grey_csdn 所有， 如有侵权，请联系我们删除。