小灰笔记

全部学习汇总： GreyZhang/c_basic: little bits of c. (github.com)C语言的基础的语法以及最基本的用法其实是很简单的，但是如果能够用这些简单的组合解决实际的问题有时候思维需要进行灵活的变通。这种变通一般就是软件设计之中的抽象技术，如果提到抽象有人会感觉不熟悉、困惑，那么最简单的学习理解方式就是结合实际的例子做一个类比。这一次来总结一下C语言中常用的一个技巧——查表法。通常来说，简单的处理使用查表法的时候都是为了追求开发上的快速而决定的。查表不见得会是最简

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!这一次来看一下MISRA C 2004中关于运行时错误的规则要求，其实这部分跟多的是在讲项目开发的实施方法上的要求而不是编码规则本身。规则要求也比较简单，只有一条。运行时中的错误至少得用下面的一种方式来检查：1， 静态分析；2， 动态分析；3， 编码进行检查；关于动态检查，可以考虑一下的几个方面：1， 算数错误。

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!20.1， 标准库中的保留符号不能够定义、重定义或者取消定义。针对这条规则，其实很好总结，总之就是一句话：不要影响标准库的功能，不要改标准库的信息。20.2， 标准库中的宏、对象以及函数的名称不能够重用。20.3， 传递给库函数的参数全都应该进行有效性的检查。20.4， 不能够使用heap。这个可能有些自己折腾着玩的小项

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!19.1， 这一条应该难以全部实现，比如在AUTOSAR的软件中进行存储分区是很常见的。而存储分区其实是在反复包含memmap的一个头文件。这样的处理机制就很难保证这一条规则的符合，好在这只是一个建议而不是强制。19.2， 这一条似乎几乎是不可能出现的一个规则要求，应该少有人会在代码文件命名的时候选择使用这样的符号来给自己增加麻烦。

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!18.1， 结构体以及联合在完成转换的时候必须保证结构体以及联合的信息完整性。这里涉及到一个概念，也就是C语言中的不完全类型。那么什么事不完全类型呢？顾名思义，也就是信息不完备的一种表达形式。比如说，声明了一个数组但是不给出数组元素的个数；再比如使用了一个结构体或者联合的名称但是却不给出其定义。这种暂时不给出的信息在编译器最后处理的时候必须

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!17.1， 这一条应该是指针和数组一起配合使用的时候要求的，指针的运算必须是指向数组或者数组元素的时候才允许。因为对于嵌入式的硬件访问，在便捷实现上可能有很多种可能。很典型的一个就是存储按照物理地址进行访问的时候，应该还是有这样的可能性。不过，相关的担忧点其实也很容易理解。因为存储排布可能情况还是很多的，而指针的增减等运算其实是跟所指向的对象类

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking16.1， 函数的参数数目不能是可变的，这个我在工作中其实是遇到很多可变的设计，自然，遇到的基本都是不符合规范的了。16.2， 函数不能够直接或者间接调用自己。这一条的主要目的是为了避免出现递归，最终导致堆栈空间使用问题。当然，针对递归的使用这里是一刀切了，直接不能用，即使是存储不会增长的尾递归也不允许使用。16.3， 函数的参数必须要有名字。关于这一条，说起来还是很有意思的。我曾

全部学习汇总： https://github.com/GreyZhang/misra_c_hackingswitch语句如果不加限制的话会引入很多复杂的表达以及bug，因此在使用的时候应该通过风格或者规则来加以限制。对我来说，比较好的一点是在编码的初期就被这些条款卡住了以至于后来看到有些代码的写法让我觉得开启了新的世界一般。随心所欲而不逾矩，规则规范的存在还是好的，至少是可以让自己期待的一切都是可控的。看上去，实现这一条规则的方式也很简单。只要是有执行内容的case最后加上一个break

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking不能够有执行不到的代码，但是防御性代码除外。关于防御性代码是什么，在后面的规则中可以继续了解。对于我现在接触的各种项目来说，其实这部分冲突最大的点或许是在于标定选择使能的分支生效。这部分的确也是在编译阶段就能够侦测到的，但是在实际的应用中其实还是得保留的。所有的非空表达式要么可以产生某种有效的效果，要么就是可以影响到程序流的选择或者改变。单纯的无效处理是不允许的。空语句之后必须要有

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!13.1， 赋值操作不能够用以产生布尔量。直白的翻译不是这样翻译，但是我觉得表达的含义应该是这样子。这里就需要有一个明确的认识了，判断条件true或者false应该使用布尔量或者布尔量表达式，但是为了在表达上更加具备可读性，我觉得可以强制做一个要求：判断条件必须是布尔量表达式，哪怕携程bool_func() == true这样的表达也是可以

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking12.1， 规则12.1(咨询):在表达式中，应该对C语言的运算符优先级规则有一定的限制。关于这一条规则，有两点需要注意：1，合理使用括号，括号并不是越多越好； 2，有时候，括号的位置会让运算的结果发生变化。在上面的也给出了一个可以参考的例子。通常，在学习阶段可能老师讲解的时候会考察大家对于结合性以及优先级的处理。但是我觉得这个并不是编程的核心点所在，如果以工程实施为目的这样的时间不用

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking这一次，把整个指针相关的这个章节一起看一下。指针的类型：指向某个对象、指向一个函数、指向void、NULL类型。指针类型转换，允许的隐式转换有：指向对象的与指向void的转换、NULL与其他的类型之间的转换。11.1，这一条要求很简单，函数指针不能够与整形指针以外的其他的类型的指针进行转换。如果这一条不遵守，可能会导致一些未定义的行为发生。11.2，指向对象的指针，可以进行转换

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking对于所有的无符号类型的常量数字都用一个后缀U来进行标识。这里面有几个可能导致误区的知识点：1. 如果数值足够大的话，其实有无这样的区分都是可以的。系统可以识别出来究竟是什么类型，但是如果数值不是很大，可能存在多种可能了。2. 接着第一条，其实还有另一个知识点。那就是数值的大小其实也是相对的，针对不同的MCU的平台，芯片本身的基础数据类型的宽度其实是有差异的。这样，在不同的平台下可能会有

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!如果将按位操作符~和<<应用于基础类型unsigned char或unsigned short的操作数，则结果应立即转换为该操作数的基础类型。看了一下这一条规则，我觉得如果拿这一条规则来考察我现在接触到的一群工程师的话，估计十之八九会全都栽跟头。当然，这样的操作在现在的软硬件开发平台上用到的不多是一个原因。另一个原因自然还是基本

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!这一对儿规则要求其实是类似的，只是一个应用于整形而另一个则适用于浮点类型。基本的要求其实是简单的：如果进行强制数据类型转换，一定是从宽值范围向窄值范围进行转换。换一个角度也可以去理解这样的要求，如果是从窄值范围到宽值范围的转换，其实隐式的转换模式基本就可以了。这里给出了一部分例子用以说明上面的情况，判断这个使用方式是否规范的一个简单的标

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!这两条规则都是关于数据类型转换的，其中10.1是针整形的，而10.2主要是针对浮点类型的。两条规则的要求其实是有相似之处的，都是关于禁止隐式数据类型转换，换言之是必须显式强制数据类型转换确认的要求。什么时候不可进行隐式的数据类型转换呢？下面几点：1，可能出现信息丢失的时候；2， 复杂表达式的时候；3， 作为函数的参数的时候；4，

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking这一条要求是针对枚举类型的量的初始化的。在枚举列表中，除非所有元素都被显式初始化，否则不能使用" = "构造来显式初始化除第一个元素外的其他成员。这个规则要求还是很简单的。要么只初始化第一个，要么不初始化，要么全都初始化。这样，就很容易记住这一条规则的要求。趁着这个机会，回忆一下自己对枚举类型应用的掌握脑子里现在存在的几条比较深刻的记忆。1，如果不进行显式的初始化，枚举类型的元素的

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking要求：数组以及结构体的非零初始值初始化要使用大括号来进行匹配的指示。关于这一条的要求有几个细则，这里面也有之前我一直不熟悉的或者错误认识的地方，在此一起纠正一下。1，多维数组的初始化，成员信息需要使用大括号来进行区分。上面的例子中给出了一个很典型的例子，一个3 * 2的数组的表示。为什么这么表示呢？这个在之前看过的C语言的三本经典教程中其实是对最原始的由来进行过解释的。其实，这个地

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!所有的自动变量在使用之前都应该被赋值。自动变量有好几种可能性，上面的规则中也做了基本的介绍。对于我接触的嵌入式系统来说，根据经验来说这部分在大多数时候都是适用于局部量。由于所使用的存储是一个动态的，如果不进行初始化的话会有随机值出现影响最终的结果。对于全局量来说，为了满足ISO C中的初始化为0的要求，一般都是通过启动代码等处理成符合要

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking 这一次，看两条规则。 具有内部链接的对象和函数的定义和声明中应使用静态存储类说明符。 这一条其实是跟前面看过的几条规则是有一定关系的，比较好的实践方式就是要保证这样的编码习惯：1，如非必须尽量不要定义可以全局访问的变量、常量以及函数； 2，尽量缩小各种变量、常量或者函数的作用域。 关于上面两条习惯的保持，在实践中有很多内容是跟static的使用方法有一...

全部学习汇总： https://github.com/GreyZhang/misra_c_hacking 所有在文件范围内的对象或函数的声明和定义都应具有内部链接，除非需要外部链接。 如果一个变量只能被同一个文件中的函数使用，那么使用static。类似地，如果一个函数仅从同一文件的其他地方调用，则使用static。使用静态存储类说明符将确保标识符只在声明它的文件中可见，并避免与另一个文件或库中的相同标识符混淆。 其实，这个就是一个static的使用应用要求。我见过很...

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking! 刚开始看这部分描述有了一点疑惑，最初我理解成了：同一个量可能在不同的文件中定义了，自然，这个显然是不合理且不允许的。 这里其实是不一样的，主要的差异在意linkage，一个典型的例子就是在链接文件或者链接命令中定义的信息。这些信息其实是可以在代码中声明并且访问的，但是对于这部分的处理，符合上面说明的可能是一个UB的行为。这里具...

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking! 看到这一条规则，让我联想到了上次的两条规则的解读。其实，在上次两条规则解读的时候我提到了这一点。只是上次提到的仅仅是函数，因为上次的规则针对的也是函数。 上面这部分笔记的截图来自我前一份笔记，我把这样的要求实现总结进了我自己的编码风格管理之中。这样的风格养成，其实最初也不是参考MISRA C来的，但是现在看来当...

全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking! 这一次看两条规则，都是关于声明的。其中8.6针对的是函数，8.7针对的是对象。 8.6，函数必须在文件的级别进行声明，否则的话可能会带来一定的混淆。其实，这一条通过简单的编码风格要求也很容易实现，只需要做一个基本要求：全局类的函数接口全都在且仅在一个头文件中声明，而静态函数只在相应的C文件的最开始部分（头文件包含等基本...

全部学习汇总：GitHub - GreyZhang/c_units: A small piece of code which can be reuse anywhere, I call it a unit. This is a collection of unit in C language! Ok, yes, it would be my toolbox. 滞环处理在嵌入式中经常用到，但是现在我手头并没有一个可以重用或者参考的架构。一般都是直接加入到代码中作为一段代码片段，但是反反复复...

Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习笔记_2004_Rule_8.5规则摘录与分析函数应在文件范围内声明。 在块作用域中声明函数可能会令人困惑，并可能导致未定义的行为。小结这样的问题我遇到的相对来说少一些，一般的开发都是傻瓜式的模板。所有的声明全都放在一个头文件，进而包含或者是直接在文件的最前面。这样，声明的机会基本进入不了代码块

使用clang-format进行代码格式排版Grey全部学习汇总： GitHub - GreyZhang/editors_skills: Summary for some common editor skills I used.使用clang-format进行代码格式排版前言我自己写代码其实也经历了很多过程，前期的确是没有关注过什么代码风格或者排版。但是随着接触到的代码越来越多，发现没有一个统一良好的编码排版风格理解管理一个工程都是很有挑战的。于是，不仅仅从编码的定义风格上，从排版的布局

MISRA_C规范学习笔记_2004_Rule_8.4Grey全部学习汇总： https://github.com/GreyZhang/misra_c_hackingMISRA_C规范学习笔记_2004_Rule_8.4规则摘录与分析存在多处声明的目标体或者函数，如果存在不同的声明类型其声明类型必须是兼容的。小结这个其实是很好理解的，主要的问题点还是在于最终执行时候的存储的分配以及解析需要对等。虽然这里并不要求百分百相同，但是从管理的规范性上还是完全一致合适一些。而简单的管理方

MISRA_C规范学习笔记_2004_Rule_8.3Grey全部学习汇总： https://github.com/GreyZhang/misra_c_hackingMISRA_C规范学习笔记_2004_Rule_8.3规则摘录与分析函数定义以及声明的定义以及声明必须一致，返回值也必须一致。小结规则要求的理解相对来说容易，类似的问题在之前看到的项目实施中有很多不同的错误出现。从基础的原因分析看，其实现在我接触到的很多工程师C语言本身的技术积淀就不是很厚。因此，类似的问题从习惯

MISRA_C规范学习笔记_2004_Rule_8.2Grey全部学习汇总： https://github.com/GreyZhang/misra_c_hackingMISRA_C规范学习笔记_2004_Rule_8.2规则摘录与分析无论何时声明或定义对象或函数，其类型都应明确声明。测试这一条其实在之前遇到的比较少，唯一的一个例外可能是unix早期版本的代码。那时候我还以为是早期语言设计的问题，现在可能不允许了。现在看来还是存在。小结这一条可能在我本人的设计经历之中，

MISRA_C规范学习笔记_2004_Rule_8.1Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习笔记_2004_Rule_8.1规则摘录与分析原型的使用使编译器能够检查函数定义和调用的完整性。 解读其实是简单的，第一句看明白了基本问题就不大了。小结首先值得一说的是，我之前接触的很多工程师这一条规则上做得不是很到位。有时候，编译器提示

MISRA_C规范学习笔记_2004_Rule_7.1Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习笔记_2004_Rule_7.1规则摘录与分析这一条的要求针对八进制以及其转义的使用。 除了0以外，其他的数值不能够用八进制。 其实我个人觉得，一切全都不要用八进制。就我目前的开发经历来说，基本上是没有遇到过八进制的开发需求的。 至于八进制

MISRA_C规范学习_2004_Rule_6.4_6.5Grey全部学习汇总： https://github.com/GreyZhang/misra_c_hackingMISRA_C规范学习_2004_Rule_6.4_6.5规则摘录与分析这两条其实多少有点相关性。 首先，位域只能够用在Int基础类型上。因为需要考虑到支持符号位。 有些数据类型的位域不能用是因为没有进行标准化的定义。 最小位应该是2个bit，因为单bit无法支持有符号的数值。小结位域的功能其实我用得还是

MISRA_C规范学习_2004_Rule_6.3Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习_2004_Rule_6.3规则摘录与分析指示大小和符号的类型应该用来代替基本的数字类型。 不应使用char、int、short、long和float、double等有符号和无符号类型的基本数值类型，但应使用特定长度类型。规则6.3有助于阐明存储的

MISRA_C规范学习_2004_Rule_6.1_6.2Grey全部学习汇总： https://github.com/GreyZhang/misra_c_hackingMISRA_C规范学习_2004_Rule_6.1_6.2规则分析与小结两条规则有一定的相关度，放在一起分析一下。 char这个基础类型只有在存储以及字符相关的应用场景中可以使用。 有三种不同的char类型，(普通)char、signed char和unsigned char。Signed char和unsi

MISRA_C学习_2004_Rule_5.7Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C学习_2004_Rule_5.7规则分析与小结不管作用域是什么，都不应该在系统中的任何文件中重用任何标识符。这条规则综合了规则5.2、5.3、5.4、5.5和5.6的规定。 如果在头文件中使用标识符名称，并且该头文件包含在多个源文件中，则不违反此规则。使用

MISRA_C规范学习_2004_Rule_5.6Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习_2004_Rule_5.6规则摘录与分析一个名称空间中的标识符不应与另一个名称空间中的标识符具有相同的拼写，结构成员和联合成员名称除外。 名称空间和作用域不同。该规则与范围无关。例如，ISO C允许标记和类型定义在同一范围内使用相同的标识符(例子

MISRA_C规范学习_2004_Rule_5.5Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习_2004_Rule_5.5规则摘录与分析静态目标或者函数标识符不应该重名。 这一条其实是建议性的，但是我觉得以后我自己软件设计中遵守应该也是有帮助的。 回忆一下，其实我处理的代码中类似的重名还是存在的。 或许，这样的设计不会引入什么bug，但

MISRA_C规范学习_2004_Rule_5.4Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习_2004_Rule_5.4规则摘录与分析这一条的解读其实很简单了，结构体以及联合的tag不能够重名。 其实，解决类似的问题还是很容易的，把tag的使用尽量作为一个形式化的信息，直接在定义的时候就定义成数据类型。这样，在数据结构层级上完成相关内容的

MISRA_C规范学习_2004_Rule_5.3Grey全部学习汇总： GitHub - GreyZhang/misra_c_hacking: MISRA C, I'm coming! Happy hacking!MISRA_C规范学习_2004_Rule_5.3规则摘录与分析这一条规则还是很好理解的，首先数据类型不要重复定义，不管是否在编译的过程中起冲突。 其次，用作数据类型的标识符不能够作为他用，不管是什么变量函数之类的名称，都得回避。小结这一条规则的真正实施其实还是很