为满足-fanalyzer分析要求，如何标注嵌入式系统中的故意无限循环？

嘿，这个嵌入式场景我太有共鸣了！碰到不可恢复的致命错误时，我们肯定不想触发一堆对象析构（毕竟平白无故增加代码体积，对资源紧张的嵌入式设备来说完全没必要），但又怕-fanalyzer这类静态分析工具把我们故意写的while(1);当成“意外死循环”来报警告，对吧？

先复盘下你的问题场景：
原来的代码逻辑是在main的业务死循环里，碰到致命错误就触发断点，然后进入死循环挂住：

int main() {
  while (1) {
    // 执行业务逻辑
    if (unrecoverable_error) {
        __breakpoint();
        while(1);
    }
  }
}

如果把while(1);换成return 0，编译器会触发main函数局部所有对象的析构流程，还会额外生成一堆析构代码，这在嵌入式场景下绝对是要避免的——Flash空间寸土寸金啊！

那怎么让-fanalyzer识别这个无限循环是我们故意写的，同时又不引入代码膨胀呢？给你两个实用的方案：

• 方案一：用noreturn属性封装致命错误处理函数
  专门写一个带__attribute__((noreturn))属性的错误处理函数，这个属性会明确告诉编译器和静态分析器：“这个函数绝对不会返回调用点”。这样分析器就不会把函数里的无限循环当成问题，编译器也不会生成多余的析构代码。
  改造后的代码如下：

  __attribute__((noreturn)) void handle_fatal_error(void) {
      __breakpoint();
      while(1); // 这里的死循环会被分析器识别为故意行为
  }
  
  int main() {
    while (1) {
      // 执行业务逻辑
      if (unrecoverable_error) {
          handle_fatal_error(); // 调用后不会返回，无需处理析构
      }
    }
  }
  

• 方案二：直接在循环前加分析器识别的注释（不推荐，不如属性靠谱）
  如果你不想单独封装函数，也可以在while(1);前加明确的注释，比如/* 故意进入死循环，处理致命错误 */，但这种方式依赖分析器的注释识别能力，稳定性不如noreturn属性，所以更推荐第一种方案。

核心思路就是：用编译器和分析器能识别的语法标记（比如noreturn属性），明确告知这是“不会返回的致命处理逻辑”，既避免了静态分析的误报，又保住了嵌入式代码的紧凑性。

备注：内容来源于stack exchange，提问作者qdot