是否定义了减去两个NULL指针的行为？

如果两个非空指针变量都被赋值，是否定义了两个非空指针变量（根据C99和/或C ++ 98）的区别NULL？

例如，假设我有一个看起来像这样的缓冲区结构：

struct buf {
  char *buf;
  char *pwrite;
  char *pread;
} ex;

说，ex.buf指向数组或某些已分配的内存。如果我的代码始终确保pwrite并pread指向该数组或指向该数组的一个数组，那么我很有信心ex.pwrite - ex.pread将始终对其进行定义。但是，如果pwrite和pread都为NULL。我是否可以期望将两者定义相减，(ptrdiff_t)0还是严格遵从的代码需要测试指针是否为NULL？请注意，我唯一感兴趣的情况是两个指针均为NULL（表示缓冲区未初始化的情况）。在满足上述假设的前提下，原因与完全兼容的“可用”功能有关：

size_t buf_avail(const struct s_buf *b)
{     
    return b->pwrite - b->pread;
}

在C99中，这是技术上未定义的行为。C99§6.5.6说：

7）为了这些运算符的目的，指向不是数组元素的对象的指针的行为与指向长度为1的数组的第一个元素的指针的行为相同，并且对象的类型为其元素类型。

[...]

9）当减去两个指针时，两个指针均应指向同一数组对象的元素，或者指向数组对象的最后一个元素之后的元素；结果是两个数组元素的下标不同。[...]

§6.3.2.3/ 3说：

值为0的整数常量表达式或转换为type的表达式 void *称为空指针常量。^55）如果将空指针常量转换为指针类型，则保证生成的指针（称为空指针）将不相等的值与指向任何对象或函数的指针进行比较。

因此，由于空指针与任何对象都不相等，因此它违反了6.5.6 / 9的前提条件，因此它是未定义的行为。但实际上，我愿意打赌，几乎每个编译器都将返回结果0，而没有任何不良副作用。

在C89中，它也是未定义的行为，尽管标准的措词略有不同。

另一方面，C ++ 03在此实例中确实定义了行为。该标准是减去两个空指针的特殊例外。C ++ 03§5.7/ 7说：

如果将值0添加到指针值或从指针值中减去，则结果将等于原始指针值。如果两个指针指向同一对象，或者两个指针都指向同一数组的末尾，或者两个指针都为空，并且两个指针相减，则结果等于等于转换为type的值0 ptrdiff_t。

C ++ 11（以及C ++ 14，n3690的最新草案）具有相同的措辞，C ++ 03，与只是微小的变化std::ptrdiff_t来代替ptrdiff_t。

我在C ++标准（5.7 [expr.add] / 7）中发现了这一点：

如果两个指针都为空，并且两个指针相减，则结果比较等于转换为std :: ptrdiff_t类型的值0

就像其他人所说的那样，C99要求在同一数组对象的2个指针之间进行加/减。NULL并不指向有效的对象，这就是为什么您不能在减法中使用它的原因。

编辑：此答案仅对C有效，当我回答时我没有看到C ++标记。

不，指针算术仅适用于指向同一对象内的指针。由于根据C标准的定义，空指针不指向任何对象，因此这是未定义的行为。

（尽管，我猜想任何合理的编译器都将返回0它，但是谁知道呢。）

在这种情况下，C标准对行为没有任何要求，但是许多实现在许多情况下确实指定了指针算术的行为，超出了标准（包括该标准）所要求的最低要求。

在任何符合标准的C实现以及几乎所有（如果不是全部）类似C的方言的实现中，以下保证将适用于任何指针p，以使*p或*(p-1)标识某些对象：

• 对于z等于零的任何整数值，指针值(p+z)和(p-z)在各个方面都将等效于p，不同之处在于，只有当p和z都恒定时，它们才会是恒定的。
• 对于q等于的任何p表达式，p-q和q-p都将产生零。

对所有指针值（包括null）保持这种保证可以消除对用户代码中某些null检查的需要。此外，在大多数平台上，生成对所有指针值都保持这种保证而又不考虑它们是否为空的代码，比专门处理空值要简单和便宜。但是，某些平台可能会陷入尝试使用空指针执行指针算术的尝试，即使加或减零也是如此。在这样的平台上，在许多情况下必须添加到指针操作以维护保证的编译器生成的空检查的数量将大大超过用户生成的空检查的数量，其结果可能会被忽略。

如果存在这样一种实现，即维持保证的成本会很高，但是很少有程序会从中获得任何好处，那么允许它捕获“空+零”计算并要求用户代码这样的实现包括手动进行null检查，以确保可以不必进行担保。预计这一津贴不会影响其余99.44％的实施，因为这些实施的担保价值将超过成本。这样的实现应该维护这样的保证，但是他们的作者不需要标准的作者告诉他们。

C ++的作者已经决定，即使在可能严重降低指针算术性能的平台上，兼容的实现也必须不惜一切代价维护上述保​​证。他们认为，即使在维护成本很高的平台上，担保的价值也将超过成本。这种态度可能受到了将C ++视为比C语言更高级的语言的渴望的影响。可以期望AC程序员知道特定的目标平台何时以异常的方式处理类似（null + zero）的情况，但是C ++程序员没想到自己会关心这些事情。因此，保证一致的行为模型是值得的。

当然，如今有关“定义的”的问题很少与平台可以支持的行为有关。取而代之的是，现在，对于编译器而言，以“优化”的名义，要求程序员手动编写代码来处理平台以前可以正确处理的极端情况，已成为一种时尚。例如，假设应该n从地址开始输出字符的代码p写为：

void out_characters(unsigned char *p, int n)
{
  unsigned char *end = p+n;
  while(p < end)
    out_byte(*p++);
}

如果p == NULL和n == 0，并且不需要特殊情况下的n == 0，则较早的编译器会生成不会产生任何副作用的可靠代码。但是，在较新的编译器上，将不得不添加额外的代码：

void out_characters(unsigned char *p, int n)
{
  if (n)
  {
    unsigned char *end = p+n;
    while(p < end)
      out_byte(*p++);
  }
}

优化程序可能会或可能无法摆脱的情况。未能包含额外的代码可能会导致一些编译器得出结论，由于p“不可能为null”，因此可以省略任何后续的null指针检查，从而导致代码陷入与实际“问题”无关的位置。