非void函数无返回值为何多数编译器仅告警而非报错？

核心原因：C++标准的未定义行为（UB）与编译器诊断自由度 #

对于返回类型非void的函数，若执行到函数结尾未返回值，C++标准将其定义为未定义行为（Undefined Behavior, UB），而非强制要求的编译错误：

• 标准仅允许编译器针对这类情况发出诊断信息（告警或错误），但不强制要求必须报错；
• 编译器可根据自身设计策略选择处理方式：GCC、Clang、NVC默认将其标记为可抑制的告警，而MSVC选择更严格的错误诊断，这两种行为均符合标准要求。

对“{foo();}是表达式”解释的驳斥 #

这个说法混淆了语法合法性与语义正确性：

• 从语法上看，函数体{foo();}是合法的复合语句，但语义上违反了非void函数的核心要求：所有执行路径必须返回一个符合类型的值；
• 标准明确排除了main函数外的非void函数无返回值的合法场景，即便函数体是复合表达式，也不能豁免返回值要求。该解释仅强调语法层面的合规性，完全忽略了语义上的安全风险，在安全敏感场景（如自动驾驶）毫无说服力。

与其他无返回值场景的差异 #

你提到的“其他无返回值场景编译器会报错”，本质是这类场景属于格式错误（Ill-formed）：

• 例如void函数返回值、函数参数类型不匹配等，这些是标准明确要求必须诊断的错误，编译器必须报错；
• 而非void函数无返回值属于UB，标准给了编译器灵活处理的空间，这是两类问题的本质区别。

面向管理层的安全说明要点 #

针对自动驾驶这类安全敏感场景，可从以下角度解释其不合理性与风险：

• 运行时风险直接关联安全：未返回值的非void函数会返回栈上的随机垃圾数据，在自动驾驶代码中，这类随机值可能被当作传感器数据、控制参数使用，直接引发致命的决策错误；
• 编译器行为可配置为严格检查：主流编译器支持通过编译选项（如GCC/Clang的-Werror=return-type）将这类告警强制转为错误，从构建阶段就拦截风险，无需修改第三方代码，仅需调整编译配置；
• 业界已有严格实践参考：MSVC将其视为错误的处理方式，证明业界存在对齐安全标准的实践，我们应在安全敏感场景采用同等严格的检查策略；
• 涉事编译器的检查局限性：部分编译器仅在函数仅有return语句时告警，属于检查不充分，需补充静态分析工具或强制编译选项，覆盖所有无返回值的非void函数场景。

内容的提问来源于stack exchange，提问作者Swift - Friday Pie