的坑有多深)
把 写成 为什么编译器不报错if (x 5) 的坑有多深有没有过这种经历代码逻辑怎么看都对但就是不按你想的走intx0;if(x5){printf(x 是 5\n);}else{printf(x 不是 5\n);}printf(x %d\n,x);你期望输出x 不是 5毕竟 x 明明赋了 0。实际输出x 是 5 x 5懵了。x 什么时候变成 5 的这就是 C 语言最坑人的键盘误触——if (x 5)不是「x 等不等于 5」是「把 5 赋给 x然后判断赋值后的值是不是 0」。你手指一滑少打了一个程序不报错、不警告、甚至很多编译器连个提示都没有直接给你把逻辑改了。更恶心的是你在 x 被偷偷改成 5 之后的每一行代码排查的时候你都盯着原始赋值的int x 0在推理——你根本就不可能想到它中途被改过。这个 bug 能活下来的根本原因是C 语言里赋值表达式有返回值。x 5不光把 5 塞进 x它本身还有值——就是这个 5。所以if (x 5)等价于if (5)而 C 语言里非 0 就是真。条件永远成立else 分支这辈子都不会执行。真实世界里被这个坑过的惨案多了去了。十几年前的 OpenSSL 心脏出血漏洞虽然根因更复杂但代码里确实出现过if (err foobar())这种把写成的情况。一个多敲少敲了的键盘失误让攻击者可以任意读取服务器内存。哪怕今天编译器已经聪明多了很多情况会给 warning但 warning 只是墙上贴了张纸条说你要不要看一下编译照样过、程序照样跑、x 照样被改成 5。if(x5)// GCC -Wall 下会警告suggest parentheses但你关了警告呢或者这个赋值藏在一长串表达式里呢if((fdopen(/tmp/log,O_RDONLY))-1)// 这个 是故意的这种写法是合法的、常用的——在 if 里赋值然后立刻判断。人眼很难一眼分辨到底是不是故意的。你读代码的时候停在这行想了两秒这人到底是忘了还是故意的怎么防有人建议把常量写左边if(5x)// 如果写成 5 x编译直接报错这确实能防止手滑——编译器不允许给常量赋值。但多数人不习惯这么写觉得别扭看着像英文倒装句。更多人选择开编译器的全部警告gcc-Wall-Wextra至少让编译器在你可能手滑的地方贴张纸条。但不是所有项目都开了最大警告也不是所有编译器都管用。说到底这是个无解的问题。C 给了你赋值返回值的权力也给了你少打一个的可能。你只能自己小心——或者祈祷 review 代码的同事眼神够好。你有没有被这个坑过有没有哪次调了半天才发现少写了一个来评论区说出你的故事。#c语言 #算法 #数据结构
