这个严格的别名示例正确吗？

Question

我在过去一周左右一直在阅读严格的别名规则并看到这篇文章：Understanding C/C++ Strict Aliasing。

本文介绍了两种交换 32 位整数的一半的方法，给出了很好的示例和违反严格别名规则的示例。不过，我无法理解其中一个示例。

此代码被描述为已损坏。

uint32_t
swaphalves(uint32_t a)
{
    a = (a >> 16) | (a << 16);
    return a;
}

给出的原因是：

这个版本看起来合理，但你不知道左右两边 |每个人都将获得a 的原始版本，或者如果其中一个人将获得以下结果 另一个。这里没有顺序点，所以我们对顺序一无所知 这里的操作，你可能会从同一个编译器使用不同的编译器得到不同的结果 优化级别。

我不同意。这段代码对我来说很好。在a = (a >> 16 | (a << 16); 行中只有一次对a 的写入，我希望a 的两次读取都发生在该写入之前。此外，没有指针或引用，也没有不兼容的类型。

我是否在此代码中遗漏了严格的别名违规，或者文章不正确？

Answer 1

此代码中的任何地方都没有指针和引用，因此严格的别名规则甚至没有进入图片。事实上，作者调用 sequence points 而不是严格的别名来证明它是未定义的断言是正确的。但是，这种推理似乎是错误的，并且代码 sn-p 具有完美定义的语义。作为Prasoon Saurav explains in more detail：

（第 1.9/15 节）运算符的操作数的值计算在运算符结果的值计算之前排序。

因此，对于 = 运算符，a 和 (a >> 16) | (a << 16) 的评估在赋值之前进行排序。这些都没有问题：虽然它的各个部分都相对于彼此没有排序，但没有写入a 仍然需要排序。

（从技术上讲，这提出了一个问题，即赋值的副作用是如何对其值计算进行排序的，但我在这方面找不到任何东西。大概它在标准中的某个地方，但我手边没有副本。我强烈怀疑它是在值计算之后排序的，原因在下一段中。）

您也可以应用常识：写入a 需要先评估(a >> 16) | (a << 16)以写入正确的值，因此它不会在评估过程中发生。这篇文章的另一个问题是，即使

uint32_t
swaphalves(uint32_t a)
{
    a = (a >> 16) | (a << 16);
    return a;
}

由于序列点而具有未定义的行为，

uint32_t
swaphalves(uint32_t a)
{
    return (a >> 16) | (a << 16);
}

不会（没有要排序的写入），因此占据文章其余大部分内容的更复杂的版本（联合、memcpy）毫无意义。