检查 NULL 时要忽略多少位？

Question

以下代码会因 seg-V 而崩溃：

// my code
int* ipt;
int bool set = false;
void Set(int* i) {
  ASSERT(i);
  ipt = i;
  set = true;
}

int Get() {
  return set ? *ipt : 0;
}

// code that I don't control.
struct S { int I, int J; }
int main() {
  S* ip = NULL;
  // code that, as a bug, forgets to set ip...
  Set(&ip->J);
  // gobs of code
  return Get();
}

这是因为虽然 i 不是 NULL，但它仍然无效。如果调用代码从 NULL 指针获取数组索引操作的地址，也会发生同样的问题。

解决此问题的一种方法是修剪低位：

void Set(int* i) {
  ASSERT((reinterpret_cast<size_t>(i))>>10);
  ipt = i;
  set = true;
}

但是我应该/可以删除多少位？

---

编辑，我不担心未定义的行为，因为无论如何我都会中止（但比 seg-v 更干净）。

FWIW：这是一个半假设的情况。导致我想到这一点的错误在我发布之前已被修复，但我之前遇到过它，并且正在考虑将来如何使用它。

为了论证可以假设的事情：

• 如果使用会 seg-v 的东西调用 Set，那么这是一个错误
• Set 可能会被不是我需要修复的代码调用。 （例如，我提交了一个错误）
• Set 可能会被我试图修复的代码调用。 （例如，我将添加健全性检查作为调试工作的一部分。）
• 以不提供有关调用 Set 的位置的信息的方式调用我的方法。 （即允许 Get 进行 seg-v 并不是调试任何内容的有效方法。）
• 代码不需要可移植或捕获 100% 的错误指针。它只需要在我当前的系统上运行足够频繁，就可以让我找到问题所在。

Answer 1

没有可移植的方法来测试除 NULL 之外的任何无效指针。在您对其进行任何操作之前，评估 &ip[3] 会给出未定义的行为；唯一的解决方案是在对指针进行任何算术运算之前测试 NULL。

如果你不需要可移植性，也不需要保证捕获所有错误，那么在大多数主流平台上，你可以检查地址是否在内存的第一页内；通常将 NULL 定义为地址零，并保留第一页以捕获大多数空指针取消引用。在 POSIX 平台上，这看起来像这样

static size_t page_size = sysconf(_SC_PAGESIZE);
assert(reinterpret_cast<intptr_t>(i) >= page_size);

，但这不是一个完整的解决方案。唯一真正的解决方案是首先修复滥用空指针的问题。

Answer 2

您根本不应该对空指针进行指针算术（包括数组索引）。

在 C++ 中，您应该使用 0，而不是 NULL。 NULL 是 c 的一个特性，在 c++ 中仍然受支持，但不是惯用的。

---

关于BCS的许多评论和编辑。这将问题从表面上相当幼稚的问题转变为更深层次的问题。但是……在像 c++ 这样宽容的语言中，要保护自己免受人们在调用您的代码之前做愚蠢的事情并不容易。

Answer 3

尝试解决未定义的行为将始终非常依赖于您的平台、编译器、版本等。如果可能的话。

常见的 *nix 永远不会精确映射地址空间的第一页来捕获空指针访问，因此您可能无需检查指针值是否在 0 到 4096 之间（或者您的系统使用的任何页面大小）。

但不要这样做，你无法防范所有可能出错的事情，而是专注于让代码正确。如果有人向您传递了无效的指针，则很可能存在指针验证检查无法修复的严重错误。

Answer 4

有什么方法可以施加一些影响来纠正错误的代码吗？这不可能有好的结果。从法律上讲，仅仅创建一个无效的指针就是未定义的行为。

如果Set总是从ip传递一个小的偏移量，并且ip总是被初始化为NULL，那么你可能会同意你正在做的事情。大多数现代系统确实具有空指针常量，因为所有位都为零，并且大多数系统都会做自然的事情。当然，绝对不能保证它能够在具有任何给定编译器和任何给定编译器选项的任何给定系统上工作，并且更改其中任何一个都可能导致它失败。

由于任何错误指针的使用都可能导致程序失败，因此您应该考虑当代码触发内存违规时会发生什么。

另外，我不知道您的 ASSERT 宏的作用，但在大多数实现中，assert 仅在调试模式下激活。如果您想将这个垃圾推入生产环境，或者以优化模式运行，您可能需要确保它仍然会更温和地失败。

Answer 5

如果您不介意非常糟糕的黑客行为，您可以使用 volatile 强制进行内存访问（注意 volatile 是邪恶的）。根据 GCC 文档，易失性访问必须跨序列点排序，因此您可以执行以下操作：

int test = *(volatile int *)i;
*(volatile int *)i = test;

我不认为 = 是序列点，但以下可能 也有效：

*(volatile int *)i = *(volatile int *)i;

Answer 6

我真的不建议尝试解决其他人代码中的错误。如果您在开发代码时没有通过调试器运行您编写的所有内容，那么再多的检查也无法帮助您发现所有问题。让他们修复他们的代码。

如果您不使用调试器，请获取一个不错的崩溃处理程序，该处理程序可以转储每个线程的调用堆栈以及尽可能多的有关程序状态的附加信息。尝试找出可能出了什么问题。

通过静态分析工具定期运行代码也可以提供帮助。

请记住，可能不是有人忘记初始化指针，也可能是其他人通过完全不相关的地方的错误内存写入覆盖了该指针。也有一些工具可以帮助追踪此类事情。

关于 NULL 与 0 的争论，#define NULL 0 更好，原因如下：

1) 当您处理指针时，您可以更容易地看到。

2) 使用 NULL 所提供的安全性不亚于或高于使用 0。那么为什么不让你的代码更具可读性呢？

3) 当 C++11 最终发布时，#define NULL nullptr 比所有这些零更容易更改。 （我想，今天您可以采用另一种方式#define nullptr 0，但是如果您正在开发跨平台代码，这可能会在将来引起问题。）

根据记录，C++ 标准明确指出空指针常量是计算结果为零的右值整数类型。因此，请不要再胡说空指针不必等于零。

Answer 7

无法以可移植方式执行此操作的原因之一是 NULL 不能保证为 0。仅指定空指针比较等于 0。您可以编写 0（或预处理器宏“NULL”） ），但编译器知道这个 0 位于指针上下文中，因此它会生成适当的代码将其与空指针进行比较，无论空指针的实际实现是什么。请参阅此处和此处 了解更多信息。将 NULL 指针重新解释为整型可能会导致它具有 true 值而不是 false。

Answer 8

您必须考虑特定的操作系统和硬件架构。如果您只对检测“接近空”的指针感兴趣，那么您可以使用 ASSERT(i > pageSize)，假设第一页在您的操作系统中始终处于写保护状态。

但是……显而易见的问题是：为什么要麻烦呢？正如您所指出的，操作系统将在这种情况下检测 null 和 SEGV，这与 ASSERT 一样好，不是吗？