为何编译会触发dangling-else警告？附具体代码场景

问题背景 #

代码示例 #

int
read_n(char *cp, int n)
{
  int nread;
  if ((nread = read(STDIN_FILENO, cp, n)) != n)
    if (nread == -1)
      die(DIE_ERROR_FMT, "failed reading input");
    else
      return nread;
  return n;
}

编译命令与警告信息 #

使用编译命令：

cc -std=c99 -Wall -Wextra -Wshadow -Wpedantic prog.c -o prog

收到警告：

le.c:343:5: warning: add explicit braces to avoid dangling else [-Wdangling-else]

提问：我清楚else会匹配最近的无else的if，且为了可读性偏好省略大括号。请问该警告触发的原因及必要性是什么？clang和gcc均会触发类似警告。

警告触发原因 #

虽然你明确知晓C语言里else会绑定到最近的未配对if，但你的代码在视觉缩进和实际语法逻辑上出现了不一致：从缩进格式看，else像是外层if的配套分支，但语法上它实际属于内层的if(nread == -1)。编译器触发这个警告，正是针对这种“视觉误导风险”——哪怕你自己清楚逻辑，后续维护代码的人很容易被缩进带偏，误解分支结构。

警告的必要性 #

• 规避人为误解：哪怕当前逻辑正确，长期维护或换开发者接手时，这种“视觉与语法不符”的写法极易让人误判分支归属，修改代码时很可能引入bug。比如有人想给外层if加额外逻辑，直接在else前加语句，结果完全不符合预期。
• 统一代码风格：强制显式添加大括号能让代码结构一目了然，消除语法歧义。可读性不能只依赖个人习惯，要兼顾团队协作的一致性，这是工业级代码维护的通用规范。
• 防御性提示：clang和gcc都默认开启这类警告，本质是从大量代码bug案例中总结的经验：这类省略大括号的嵌套if写法是bug高发区，提前警告能帮开发者规避潜在风险。

内容的提问来源于stack exchange，提问作者user129393192