C 为什么要在使用指针后检查指针是否为空？

我正在读这篇文章，它在页面底部包含一个来自Linux内核的示例（略经编辑）

文章声称

正如我们现在很容易看到的，这两种情况都不需要空指针检查。该检查已删除，可能会造成可利用的安全漏洞

如果他们取消对空指针的引用，它是否会出错？他们甚至连支票都拿不到，对吗

此漏洞可能是什么

编辑： 我读了这篇文章，我明白了！我想知道为什么人们会这样编码，也许是故意的？至少对我来说，仅仅因为一个家伙在他的博客上声称这是一个错误，并不意味着这是一个错误，所以我想再次检查它。怎么了

如果他们取消对空指针的引用，它是否会出错

是的，还有一个注释：

这里的习惯用法是获取指向设备结构的指针，并对其进行测试 null，然后使用它。但是有个问题！在此函数中 指针在空检查之前取消引用

怎么了

通过在检查NULL之前取消对指针的引用，编译器可以认为：“哦，指针被取消引用了，所以在程序的这一点上它不能为NULL，否则取消引用会起作用。所以我可以安全地省略整个代码路径。”

写这封信的人的想法？不知道，这是一种糟糕的风格。每个具有公开符号的函数应该做的第一件事是验证其输入（静态内联的短辅助函数可能不受该规则的约束，但这些函数的调用方必须确保所有参数都有效）

---

实际上，这意味着，在某种树遍历方法中，首先应该检查传递给函数的结构和值中的所有指针是否为NULL。有些人喜欢广度优先，我通常使用深度优先。重要的一点是，在取消引用之前检查每个指针是否为空。

这个问题似乎与主题无关，因为它涉及对相关文章的简单误读。重新引用虚拟内存地址0不一定会产生SEGFULT。它取决于可执行映像的配置访问权限，这很可能是该地址的RO（甚至RW）。如果你仔细阅读所有段落，你可能会得到所有答案。“为什么人们以这种方式编码”可能是一个或两个试图“初始化所有变量”和另一个“测试所有输入”的编码器，但顺序错误。我读了两遍该段落。Linux内核有许多有趣的技巧，仅仅因为有人认为这是一个错误，并不能100%地证明它是错误的。你确定这只是开发人员的疏忽，而不是出于某种原因吗？@user10607，我认为这一定是疏忽，看看@user10607 Undefined behavior is Undefined。如果内核程序员认为他们可以预测编译器将对调用未定义行为的程序执行什么操作，或者编译器的未来版本将执行什么操作，那么这是错误的。所以，如果它是故意写的，它仍然是一个错误，只是一个更深层次的错误，需要对有意把它放进去的开发人员进行教育。此外，John Regehr不仅仅是“某个人”，他也不是唯一一个认为Linux源代码错误的人。每一个本可以改变GCC的GCC开发人员都同意不需要特殊的标志来发出预期的代码。

static void __devexit agnx_pci_remove (struct pci_dev *pdev)
{
  struct ieee80211_hw *dev = pci_get_drvdata(pdev);
  struct agnx_priv *priv = dev->priv; 

  if (!dev) return;

  ... do stuff using dev ...
}