2016年嵌入式开发中静态代码分析器的七种用途
使用静态代码分析器有助于提升固件和捕获编译器难以察觉的问题。标准的C语言编译器在检查语法错误方面做得很好，并且能将其编译成可执行的程序。如果代码被编译成功，编译器就会默认一切都很好，但可能还是会存在许多的错误。静态代码分析器在下列场景中就能大展身手。以下yjbys为大家推荐每一位嵌入式软件开发工程师都应该熟悉的静态代码编译器的七种用法。
用途#1 - 捕捉潜在的漏洞
静态代码分析器广为人知的用途之一就是扫描软件中潜在的问题和漏洞。这些问题小到switch case遗漏了break语句，大到缓存溢出的潜在风险。静态代码分析器能够发现那些容易被编译器或者代码审核人员忽略的问题。在开发的早期阶段配置一个静态代码分析器在实践中能够确保潜在风险被立即处理，而不是等到开发的后期阶段。
用途#2 - 强制执行代码规范
执行代码规范是确保软件开发一致性和代码可读性的重要举措。代码规范不仅会涉及代码可读性等问题，它还能迫使代码变得优雅。一个典型的例子就是许多静态代码分析器支持MISRA C。静态代码分析器能够确保开发者没有违背大多数推荐实现方法，也没有违背标准的优雅实践(但是有些规则要求人工检查，机器无法自动判别)。如果真的发生了违规行为，静态分析器会将违规行为报告给开发者，开发者可以给予纠正。使用静态分析器能够快速判断代码是否遵循了已定义的标准。
用途#3 - 确保严格执行ANSI-C标准
那些想严格按照ANSI-C标准开发可移植软件的开发者可以用静态代码分析器判断是否有非标准的用法混杂在代码里。将分析器设置为“strict”将会查找出那些可移植性较差的或者兼容性较弱的代码区域。开发者随后可以再次检查这部分代码，使得软件更好地遵守ANSI-C标准，或者至少在文档中注明这部分代码。
用途#4 - 强大的'类型检查功能
C语言并不支持强类型检查。在C语言中，如果开发者自己创建了一种类型，编译器会忽略新类型而使用底层的C语言类型。
举个例子，如上图所示，编译器会视变量Var1为int类型(实现时定义)而不是新的MyEnum_t类型。开发者也许想区分int和MyEnum_t两种类型，并让编译器在两者混用之时做出警告。然而，在第13行编译器并不认为把变量Var2(底层是int类型)的值赋给变量Var1(底层也是int类型)存在什么错误。静态代码分析器能够设置严格的类型检查，将Var1=Var2因不同类型间的赋值而置为高亮，以及检查出其它不符合开发者本意的问题。
用途#5 - 提供量纲检查
1998年发射失败的火星气候探测器是我最关注的航空器失事事故之一。航空器的失败是由于输入轨道插入参数时使用了非标准的lbs*s 而不是 N*s (哎呀!)。火星气候探测器的失事永远警示着我们确保度量单位正确的重要性。但C编程语言没有提供任何的量纲分析来确保计算的一致性。但是，静态代码分析器能够完成这些检查，以确保不会将千米误乘以英尺从而得到一个错误的结果。量纲分析的设置在各种工具中各不相同，但开发者应该好好利用这个重要的特性。
用途#6 - 支持基本的堆栈分析
理解栈的最坏使用场景是开发任何实时嵌入式系统的关键。有很多的方法能分析和确定堆栈的最坏情况下的的使用状态，但可以用静态代码分析器来找找合理使用堆栈的感觉。静态分析器可以计算函数的堆栈使用情况和调用图来给出堆栈所需的大致空间。静态分析工具还可以帮助深入了解程序对函数调用，以及函数结果的确定性。使用静态分析来熟悉堆栈的使用和最坏工作状态有助于初步理解堆栈的最坏状态分析。
用途#7 - 帮助检查线程
静态分析工具也可以用来查看在相同处理器上同时执行的线程和任务所出现的问题。举个例子，分析工具可以识别是否有与加锁或解锁互斥相关的任何异常。线程检查对在实时系统中查找问题非常有效，但配置此类分析却要花费很大的代价。只要能发现存在异常的线程，这种代价还是值得付出的。
总结
静态分析是开发人员开发实时系统的一个宝贵工具。静态分析器的七种用途只是其强大功能的几个例子。静态代码分析器的使用可以大大提高代码的质量和鲁棒性，如果设置得当，甚至可以确保代码与常见的或自定义的编码标准的一致性。
【2016年嵌入式开发中静态代码分析器的七种用途】相关文章：