快捷搜索:

在C语言中用ASSERT调试的八个技巧

在C语言中用ASSERT调试的八个技巧

C语言中的ASSERT(断言)宏是嵌入式软件开发人员可以使用的最好的调试工具之一。虽然ASSERT功能强大,但我很少看到它被实施,并且在一些使用它的案例中,它的实施要么是有瑕疵的要么是不正确的。以下一些技巧将不仅能够帮助阐明在何时、何地使用ASSERT,而且还能阐明如何开始正确使用它。

本文引用地址:

技巧1:记住ASSERT的定义

对许多开发人员来说,断言是一个令人困惑的话题,因为它们的许多使用方式与其设计初衷背道而驰。我见到的最清晰的断言定义是这样的:

“断言是在程序某个特定点的一个布尔表达式,除非程序中有缺陷(Bug),否则它的值将为真。”

想要理解上述断言定义的开发人员应该留意下面三个要点:

·断言会评估一个表达式是真还是假

·断言是在代码中的某个点对系统状态的一种假设

·断言会验证系统假设,如果不为真,就表明代码中有一个缺陷

技巧2:使用ASSERT验证函数的先决条件

断言非常适合契约式设计环境,在这种环境中,开发人员非常清晰地定义了某个函数的先决条件。断言可以用来检查该函数的输入是否满足先决条件。就拿图1所示的代码片段为例:

在C语言中用ASSERT调试的八个技巧

图1:函数的先决条件

函数的STate输入应该在定义的系统状态范围内。如果State不是有效的状态值,那么它就不是错误,而是缺陷!断言可以用来验证State是有效的假设,如图2所示:

在C语言中用ASSERT调试的八个技巧

图2:对函数先决条件应用断言

在State不小于最大值的事件中,断言表达式将被评估为假,程序于是将停止执行。停止程序执行可以让开发人员很容易马上看到哪里的代码出错,而不是过段时间以后才知道。

技巧3:使用ASSERT验证函数的后置条件

断言也能用来验证契约式设计环境中对某个函数输出的假设。例如,如果前面定义的System_StateSet函数返回SystemState变量,开发人员可以预计它也在期望的范围之内。断言可以用来对缺陷进行监视,如图3所示。

在C语言中用ASSERT调试的八个技巧

图3:对函数后置条件应用断言

开发人员在查看上述代码后可能会感到这些检查毫无意义。刚刚才设置好的SystemState怎么就会出现大于SYSTEM_STATE_MAX的值呢?答案是这确实不应该出现,然而有时候会莫名其妙地发生改变,也许是通过中断或并行线程,此时断言可以立即标志出这个缺陷。

技巧4:不要把ASSERT用于错误处理

在记住断言定义之后,开发人员应该切记:断言是用于检测缺陷的,不能用于错误处理。错误处理是设计用于响应错误的用户输入和意外的事件顺序的软件。错误在系统中预料是会发生的,但仅仅是因为有无效的输入而并不意味着代码中有缺陷。错误处理应该与缺陷寻找分开来。错误使用断言的一个典型例子是,在试图打开一个文件用于读取时去检查文件的指针,如图4所示。

图4:ASSERT的不当使用

读者可以清楚地看到,试图打开文件的结果与文件系统的状态和用户数据有关,而与代码中的缺陷一点关系也没有。开发人员应该编写错误处理程序,而不是用断言,以便在文件不存在时,错误处理程序可以用一些默认可用数据来创建它,以便后续代码继续操作。

技巧5:ASSERT仅对开发有意义,不能用于生产

开发ASSERT宏的原始意图是在开发过程中启用它,在后面生产时要禁用。可以用NDEBUG宏激活和禁用ASSERT。正确实施的断言在被禁用后应该对嵌入式系统基本没有影响。

问题是,如果测试是在断言启用的情况下进行的(为了捕捉任何缺陷,应该这样做),那么现在禁用断言将导致交付的产品与测试的产品处于不同的状态。断言确实会占用一些代码空间,但更重要的是,它们需要占用少量的时钟周期来评估它们的布尔表达式。禁用ASSERT可能对具有有限资源的裸机系统的执行时序产生很大影响,从而导致在生产系统中产生新的缺陷。开发团队需要判断是否值得冒关闭断言的风险。

一种替代方案是保留断言在激活状态,而将它们的输出重定向到一个系统日志。这样可以确保任何挥之不去的缺陷很容易被识别,而且能避免中止系统的运行,而中止系统可不是明智之举。

技巧6:不允许断言有副作用

您可能还会对下面的文章感兴趣: