联合UB的非活动成员的指针算术？

Question

让我们考虑这个示例代码：

struct sso
{
    union {
        struct {
            char* ptr;
            char size_r[8];
        } large_str;
        char short_str[16];
    };

    const char* get_tag_ptr() const {
        return short_str+15;
    }
};

在[basic.expr] 中指定，只要结果指向数组的另一个元素（或超过对象或最后一个元素的结尾），就允许使用指针运算。然而，如果数组是联合的非活动成员，则在此设置中没有指定会发生什么。我相信这不是问题short_str+15 绝不是 UB。对吗？

_{The following question 清楚地表明了我的意图}

Answer 1

编写return short_str+15;，您获取一个对象的地址，该对象的生命周期可能尚未开始，但这不会导致未定义的行为，除非您取消引用它。

[basic.life]/1.2

如果对象是联合成员或其子对象， 它的生命周期仅在该联合成员被初始化时才开始 工会成员，或如[class.union] 中所述。

和

[class.union]/1

在联合中，一个非静态数据成员是活动的，如果它的 name 指的是生命周期已经开始但尚未结束的对象 ([basic.life])。至多一个对象的非静态数据成员 union 类型可以随时激活，也就是最多的值 其中一个非静态数据成员可以存储在任意位置的联合中 时间。

但是

[basic.life]/6

在对象的生命周期开始之前但在对象的存储之后 对象将占用已被分配，或者，在一个生命周期之后 对象已经结束并且在对象占用的存储空间之前 重用或释放，任何表示该地址的指针 可以使用对象将要或曾经所在的存储位置 但仅限于有限的方式。对于正在建造的物体或 破坏，见[class.cdtor]。否则，这样的指针指向已分配 存储（[basic.stc.dynamic.allocation]），并像使用指针一样使用指针 类型 void* ，定义明确。通过这样的指针间接是 允许，但生成的左值只能以有限的方式使用， 如下所述。
- [列表与工会无关]

Answer 2

联合成员上的指针算术是否会导致别名取决于指针最终将如何使用。在补充标准的实现上，保证“类型访问”规则将仅在存在实际别名的情况下应用，或者（对于 C++）在涉及具有非平凡语义的类型的情况下，指针操作的有效性与它们是在活动成员还是非活动成员上执行的关系不大。

考虑，例如：

#include <stdint.h>

uint32_t readU(uint32_t *p) { return *p; }
void writeD(double *p, double v) { *p = v; }

union udBlob { double dd[2]; uint32_t ww[4]; } udb;

uint32_t noAliasing(int i, int j)
{
  if (readU(udb.ww+i))
    writeD(udb.dd+j, 1.0);
  return readU(udb.ww+i);
}

uint32_t aliasesUnlessDisjoint(int i, int j)
{
  uint32_t *up = udb.ww+i;
  double *dp = udb.dd+j;

  if (readU(up))
    writeD(dp, 1.0);
  return readU(up);
}

在 readU 执行期间，不会通过任何其他方式访问通过 *p 访问的存储，因此在执行该函数期间没有别名。同样在writeD 的执行过程中。在noAliasing 的执行期间，所有将影响与udb 关联的存储的所有操作都是使用从udb 派生的指针执行的，并且显然具有明显不重叠的活动生命周期，因此那里没有别名。

在aliasesUnlessDisjoint的执行过程中，所有的访问都是使用派生自udb的指针进行的，但是在dp的创建和使用之间通过up访问存储，通过@987654332访问存储@在up的创建和使用之间。因此，*dp 和 *up 将在 aliasesUnlessDisjoint 执行期间出现别名，除非 udb.ww[i] 和 udb.dd[j] 占用不相交的存储空间。

请注意，gcc 和 clang 都应用类型访问规则，即使在上面的无别名函数这样没有实际别名的情况下也是如此。尽管标准明确规定someArray[y] 形式的左值表达式等同于*(someArray+(y))，但如果使用[] 语法，gcc 和clang 将只允许可靠访问联合中的数组成员。例如：

uint32_t noAliasing2(int i, int j)
{
  if (udb.ww[i])
    udb.ww[j] = 1.0;
  return udb.ww[i];
}
uint32_t noAliasing3(int i, int j)
{
  if (*(udb.ww+i))
    *(udb.dd+j) = 1.0;
  return *(udb.ww+i);
}

虽然 gcc 或 clang 为noAliasing2 生成的代码在对udb.dd[j] 进行操作后会重新加载udb.ww[i]，但noAliasing3 的代码不会。根据标准，这在技术上是允许的（因为所写的规则不允许在任何情况下访问udb.ww[i]！），但这绝不意味着对作者认为 gcc 和 clang 的行为适用于高质量的实现。纯粹看标准，我看不出任何特定的 noAliasing 形式应该或多或少比任何其他形式有效，但考虑在 -fstrict-aliasing 模式下使用 gcc 或 clang 的程序员应该认识到 gcc 和 clang区别对待。