C标准寻址简化不一致

Question

第 6.5.3.2 节“地址和间接运算符”¶3 说（仅相关部分）：

一元 & 运算符返回其操作数的地址。 ... 如果操作数是一元 * 运算符的结果，则该运算符和 & 运算符都不会被计算，结果就好像两者都被省略了，除了对运算符的约束仍然适用并且结果不是左值。类似地，如果操作数是 [] 运算符的结果，则不会计算 & 运算符和 [] 隐含的一元 *，结果就像删除了 & 运算符一样并且 [] 运算符更改为 + 运算符。 ...

这意味着：

#define NUM 10
int tmp[NUM];
int *i = tmp;
printf("%ti\n", (ptrdiff_t) (&*i - i) );
printf("%ti\n", (ptrdiff_t) (&i[NUM] - i) );

应该完全合法，打印 0 和 NUM (10)。标准似乎很明确，这两种情况都需要优化。

但是，它似乎不需要优化以下内容：

struct { int a; short b; } tmp, *s = tmp;
printf("%ti\n", (ptrdiff_t) (&s->b - s) );

这似乎非常不一致。我看不出上面的代码没有理由不打印sizeof(int) 加上（不太可能）填充（可能是4）。

简化&-> 表达式在概念上（恕我直言）与&[] 相同，即简单的地址加偏移量。它甚至是一个可以在编译时确定的偏移量，而不是可能在运行时使用 [] 运算符确定。

为什么这看起来如此不一致，有什么理由吗？

Answer 1

在您的示例中，&i[10] 实际上是不合法的：它变成了i + 10，然后变成了NULL + 10，并且您不能对空指针执行算术运算。 （6.5.6/8列出了可以进行指针运算的条件）

反正这条规则是在C99中加入的；它在 C89 中不存在。我的理解是，它在很大程度上是为了使代码像下面这样定义明确：

int* begin, * end;
int v[10];

begin = &v[0];
end = &v[10];

最后一行在 C89（和 C++）中在技术上是无效的，但由于这条规则，在 C99 中是允许的。这是一个相对较小的更改，使常用的构造得到良好定义。

因为您不能对空指针执行算术运算，所以您的示例 (&s->b) 无论如何都是无效的。

至于为什么会出现这种“不一致”，我只能猜测。很可能没有人想过让它保持一致，或者没有人看到一个令人信服的用例。这有可能被考虑并最终被拒绝。在the Rationale 中没有关于&* 减少的评论。您或许可以在 the WG14 papers 中找到一些确定的信息，但不幸的是，它们似乎组织得非常糟糕，因此浏览它们可能很乏味。

Answer 2

我认为该规则不是为了优化目的而添加的（它带来了什么而不是 as-if 规则？）但是允许 &t[sizeof(t)/sizeof(*t)] 和 &*(t+sizeof(t)/sizeof(*t)) 如果没有它，这将是未定义的行为（直接写这样的东西可能看起来很傻，但是添加一层或两层宏就会有意义）。我没有看到特殊套管 &p->m 会带来这种好处的情况。请注意，正如詹姆斯指出的那样，&p[10] 带有 p 一个空指针仍然是未定义的行为； &p->m 带有 p 的空指针同样会保持无效（我必须承认，当 p 是空指针时我看不到任何用处）。

Answer 3

我相信编译器可以选择以不同的方式打包，可能会在结构成员之间添加填充以提高内存访问速度。这意味着您不能肯定地说b 将总是 是 4 的偏移量。单值不存在同样的问题。

此外，编译器在优化阶段可能不知道结构在内存中的布局，从而阻止了任何与结构成员访问和后续指针转换有关的优化。

---

编辑：

我有另一个理论......

很多时候编译器会在词法分析和解析之后优化抽象语法树。这意味着它将找到诸如抵消的运算符和评估为常数并将树的这些部分减少为一个节点的表达式之类的东西。这也意味着关于结构的信息不可用。在某些代码生成之后发生的后续优化过程可能会考虑到这一点，因为它们有额外的信息，但对于诸如修剪 AST 之类的事情，这些信息尚不存在。