gpt4 book ai didi

捕获带有副作用的 assert()

转载 作者:太空狗 更新时间:2023-10-29 16:38:22 25 4
gpt4 key购买 nike

我们有几个中等大小的 C 代码库,可以接收来自具有各种经验水平的开发人员的提交。一些缺乏纪律的程序员提交 assert()具有副作用的语句会导致禁用断言的错误。例如。

assert(function_that_should_always_be_called());

我们已经使用我们自己的 assert()实现,但使用 NDEBUG 评估表达式定义会导致 Not Acceptable 性能下降。是否有我们可以传递的 GCC 扩展或标志来触发这些的编译时警告/错误?通过足够简单的控制流程,GCC 应该可以确定您只是在调用纯函数。

最佳答案

尽管这个问题收到了许多无用的非答案,但我认为它在遗留代码库的上下文中具有很多优点。
想象一下,多年来积累了许多断言,但是由于没有使用 NDEBUG 构建/测试的习惯,一些副作用已经渗透到断言中,现在你不敢再禁用断言了。
您可以打开 NDEBUG 并在您的测试套件中检测到一些测试失败,但是将测试失败与“有效”断言联系起来并不简单,因为它可能离您检测到失败的点很远。即使是具有良好覆盖率的测试套件也不能被认为是完整的。
您可以对代码中的所有断言进行代码审查,但这可能需要大量工作并且容易出现人为错误。如果一些静态分析已经可以消除所有可以证明没有出现副作用的断言,并且您只需要调查那些不能保证它们不存在的情况,那就更好了。
以下是如何使用编译器的优化器来进行这样的静态分析。假设您组织替换 assert 的定义宏:

extern int not_supposed_to_survive;
#define assert(expr) ((void)(not_supposed_to_survive || (expr)))
如果 expr有任何副作用,效果的执行取决于全局变量 not_supposed_to_survive 的值.但是如果 expr没有任何副作用,全局变量的值无关紧要(注意 expr 结果被丢弃)。 一个好的优化器知道这一点,并将消除全局变量 not_supposed_to_survive 的负载。 ,因此变量的名称。
如果我们的程序不包含符号 not_supposed_to_survive 的定义,当负载没有被消除时,我们会得到一个链接错误,我们可以用它来检测一个潜在有效的断言。
例如。使用 gcc 4.8:
int g;

int foo() { return ++g; }

int main() {
assert(foo());
return 0;
}

gcc -O2 assert_effect.c
/tmp/ccunynya.o: In function `main':
assert_effect.c:(.text.startup+0x2): undefined reference to `not_supposed_to_survive'
collect2: error: ld returned 1 exit status
编译器帮助我找到了一个可疑的断言!另一方面,如果我替换 ++g通过 g+1 ,链接错误消失,我不必调查。事实上,这种说法保证是无害的。
当然,可证明无副作用的概念受到优化器“可以看到”的限制。为了进行更精确的分析,我建议使用链接时优化 ( gcc -flto) 跨编译单元进行分析。
作为一个轻微的可用性改进,在 GCC 4.4 和更高版本上,可以使用 error 在编译时(而不是链接时)获得人类可读的错误消息。功能属性。由于这个属性只对函数起作用,对变量不起作用,我们还需要告诉 GCC 它是一个纯函数,这意味着函数本身不会有副作用。这确保了如果返回值不相关,可以安全地删除对函数的调用。
extern int not_supposed_to_survive() __attribute__((pure)) __attribute__((error("assert() cannot be proven to have no side effects")));
#define assert(expr) do { (void)(not_supposed_to_survive() || (expr)); } while(0)
更新:我使用 gcc 5.3 在现实生活中的 C++ 代码库上应用了带有全局变量的简单变体。要使用链接时优化,您基本上使用 gcc -flto -g作为编译器/链接器(编译器/链接器上的 -g 选项,用于获取链接错误的行引用)和 gcc-argcc-ranlib作为任何静态库的归档器/索引器。
这种设置可以极大地减少我必须调查的断言数量。用最少的人力,我就能把断言清理干净。我仍然不得不手动拒绝的误报是由于:
  • 虚函数调用
  • 非平凡的循环/递归(优化器无法证明它们是有限的)

  • 此外,我还会得到一些确实包含副作用的断言,但它们是无害或不重要的,例如:
  • 包含日志语句的函数
  • 缓存其结果的函数
  • 关于捕获带有副作用的 assert(),我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/10593492/

    25 4 0
    Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
    广告合作:1813099741@qq.com 6ren.com