没人喜欢被管束。当交警要求你规范驾驶减速行驶时，你的第一反应很少会是由衷感谢。但当你开车经过一辆撞在树上的汽车，周围闪烁着警灯，救援设备四处可见时，或许你会意识到警察的建议是有道理的。
对于 FBI 和 CISA 对缓冲区溢出问题的严厉态度，这一点毋庸置疑。这些机构关注可能威胁企业 IT 系统、造成严重事故的安全漏洞，他们已经见过太多类似情况，因此感到愤怒。编写代码时犯错并不是罪过，任何值得做的人类活动都难免会出错。问题在于这类漏洞是可以避免的，而且几十年来一直如此，但大型科技公司仍在源源不断地产生这样的问题，就像教堂长椅上不断涌出的蛀虫。他们说"够了"，这种说法很有道理。
你应该都了解缓冲区溢出。当程序员将数据从 A 移动到 B，却没有检查 A 是否总能装入 B 时，就会出现问题。当 A 装不下时，数据就会被复制到 B 之外的内存中，这可能会造成灾难性后果。让我们把那块内存称为 C，代表灾难 (Catastrophe)。或混乱 (Chaos)。或者就是 C 语言本身。
联邦机构建议的众多解决方案之一是放弃 C 语言及其混乱的家族，转而使用具有健全防御机制、能够防止缓冲区溢出的现代语言。C 语言显然不具备这种特性。它就像一把没有安全防护的电锯，诞生于这样一个时代：如果程序员想要切断自己的股动脉，那是他们的自由。有些马戏团演员可以玩杂耍电锯，但你绝对不会想在圣诞节把电锯杂耍套装作为家庭礼物送人。
正如联邦机构指出的，你不必完全放弃 C 语言就能提高安全性。你可以通过多种方式进行更好的测试，可以使用安全的编码实践和检查工具。现在的计算机可以在几分钟内编译整个 Linux 源代码。没有理由不利用这种原始计算能力来做更多的代码测试工作。
这正是安全漏洞观察者感到沮丧的核心原因。这些公司在没人要求的 AI 上烧掉数十亿美元，却不愿意花费一小部分资金来清理自己制造的混乱。
所有向他人提供服务和商品的人都要承担责任和后果。一个将 240 伏电路接到 115 伏插座的电工活不了多久。同样，一个用一英寸管道做马桶出水口的水管工也会遇到真正的缓冲区溢出问题。然而，像 Microsoft 这样的公司在明知可以避免的情况下，仍然对数百万客户这样做，而且可以继续这样做而不受惩罚。
是的，测试成本很高，而且不能保证绝对安全。但是请想想：如果测试的代码本身错误较少，测试就会变得更快、更容易、更便宜。当某类错误在流程早期就被消除时，就不需要再检查这类错误了。这就把我们带回到编码平台的选择，特别是编程语言的选择这个话题。
改变语言很困难，而且你在某个领域越优秀，改变就越困难。世界上最好的电锯杂耍者不会想换成精密安全切割器。如果你的业务建立在电锯杂耍套装的生态系统上，而流的血不是你的，那为什么这是别人的事？对一个组织来说，挑战不仅仅是技术层面的，还包括文化和个人层面，这不应该被低估。看看 Linux 内核中关于 Rust 的争论，其中 Linus 不得不用他的驯兽鞭来驯服一些大家伙。
但这些都不是不做出改变的借口。终有一天，C 语言会成为 21 世纪的 COBOL，这一天来得越快，信息高速公路上的血迹就会越少。当你明知如何把事情做好却依然做得很糟糕时，迟早会导致无关紧要，甚至灭绝。一旦你拥有高效的流程和优秀的人才，编写和发布更好的代码就会成为竞争优势。
转型成本是一次性的，而持续的节省是永远的。你想多快到达那里？你正在做什么来实现这一目标？
当罪过变成犯罪时，站在正义一边也是很好的。如果不良实践被多次指出却仍被故意忽视，那么将其定为可诉讼就成为可能。一个新法律，甚至仅仅是对现有法律的一个法庭案例就可以做到这一点——由于可避免的糟糕代码造成的漏洞使公司明确承担责任。从法律角度定义糟糕的代码很难，但将使用公认的良好方法作为可接受的辩护符合逻辑。
这个列表不会包括"不要使用 C 语言"，至少不会立即包括。如果问题持续足够长的时间，有一天可能会需要这样做。最好不要让这种情况发生，而是让 C 语言成为历史，至少在生产代码中是这样，因为这些代码不仅可能切断你自己的腿，还可能伤害数百万用户。那些电锯最好尽快生锈掉。
