通过不兼容的指针复制变量的位是否总是未定义的行为？

Question

例如，这是否会

unsigned f(float x) {
    unsigned u = *(unsigned *)&x;
    return u;
}

平台上导致不可预测的结果，而

• 在unsigned 和 float 均为 32 位的
• 指针对于所有类型
• unsigned 都具有固定大小code> 和 float 可以在内存的同一部分存储和加载。

我了解严格的别名规则，但大多数显示违反严格别名的问题案例的示例如下所示。

static int g(int *i, float *f) {
    *i = 1;
    *f = 0;
    return *i;
}

int h() {
    int n;
    return g(&n, (float *)&n);
}

根据我的理解，编译器可以自由地假设 i 和 f 是隐式restrict。如果编译器认为 *f = 0; 是多余的（因为 i和 f 不能别名），或者如果考虑到 i 和 f< 的值，它可能是 0 /code> 是相同的。这是未定义的行为，因此从技术上讲，任何其他事情都可能发生。

然而，第一个例子有点不同。

unsigned f(float x) {
    unsigned u = *(unsigned *)&x;
    return u;
}

抱歉我的措辞不清楚，但一切都是“就地”完成的。除了“复制 x 的位”之外，我想不出编译器可以解释该行 unsigned u = *(unsigned *)&x; 的任何其他方式。到u”。

在实践中，我在 https://godbolt.org/ 中测试的各种架构的所有编译器经过全面优化后都会产生相同的结果第一个示例的结果，以及第二个示例的不同结果（0 或 1）。

我知道从技术上讲，unsigned 和 float 具有不同的大小和对齐要求，或者应该存储在不同的内存段中。在这种情况下，即使第一个代码也没有意义。但在大多数现代平台上，以下内容成立，第一个示例仍然是未定义的行为（它会产生不可预测的结果）吗？

• unsigned 和 float 都是 32 位，
• 所有类型的指针都有固定的大小
• unsigned 和 float 可以存储到内存的同一部分并从内存的同一部分加载。

---

在实际代码中，我确实编写了

unsigned f(float x) {
    unsigned u;
    memcpy(&u, &x, sizeof(x));
    return u;
}

优化后的编译结果与使用指针转换相同。这个问题是关于对代码严格别名规则的标准的解释，例如第一个示例。

Answer 1

通过不兼容的指针复制变量的位总是未定义的行为吗？

是的。

规则是 https://port70.net/~nsz/c/ c11/n1570.html#6.5p7：

对象的存储值只能由具有以下之一的左值表达式访问
以下类型：

• 与对象的有效类型兼容的类型，
• 与对象的有效类型兼容的类型的限定版本，
• 是与有效类型对应的有符号或无符号类型的类型
  对象，
• 是与合格版本相对应的有符号或无符号类型的类型
  对象的有效类型，
• 聚合或联合类型，其中包含上述类型之一
  成员（递归地包括子聚合或包含联合的成员），或
• 字符类型。

对象x 的有效类型是float - 它是用该类型定义的。

• unsigned 与 float 不兼容，
• unsigned 不是 float 的合格版本，
• unsigned 不是 float 的有符号或无符号类型，
• unsigned 不是与 float 的限定版本对应的有符号或无符号类型，
• unsigned 不是聚合或union 类型
• 和 unsigned 不是字符类型。

违反了“应”，它是未定义的行为（请参阅 https:// port70.net/~nsz/c/c11/n1570.html#4p2 ）。没有其他解释。

我们还有 https://port70.net/~nsz/c /c11/n1570.html#J.2：

在以下情况下该行为未定义：

• 对象可以通过允许类型 (6.5) 的左值以外的方式访问其存储值。

Answer 2

正如卡米尔所解释的，这是 UB。即使 int 和 long（或 long 和 long long），即使它们是别名，也不兼容别名。相同的尺寸。 （但有趣的是，unsigned int 与 int 兼容）

这与大小相同或使用注释中建议的相同寄存器集无关，主要是一种让编译器在优化时假设不同指针不指向重叠内存的方法。他们仍然必须支持 C99 Union 类型双关，而不仅仅是 memcpy。因此，例如，如果 dst 和 src 具有不同类型，则 dst[i] = src[i] 循环在展开或矢量化时不需要检查可能的重叠。¹

如果您要访问相同的整数数据，则标准要求您使用完全相同的类型，仅模数，例如 signed 与 unsigned 和 const< /代码>。或者您使用（无符号）char*，这类似于 GNU C __attribute__((may_alias))。

---

你的问题的另一部分似乎是为什么它在实践中似乎有效，尽管有 UB。
您的 godbolt 链接忘记链接您尝试过的实际编译器。

https://godbolt.org/z/rvj3d4e4o 显示 GCC4.1，来自 GCC 之前的版本不遗余力地支持像这样“明显的”本地编译时可见的情况，有时不会使用不可移植的习惯用法来破坏人们的错误代码 像这样。
它会从堆栈内存加载垃圾，除非您首先使用 -fno-strict-aliasing 使其 movd 到该位置。 （存储/重新加载而不是 movd %xmm0, %eax 是一个错过优化的错误，在大多数情况下已在更高版本的 GCC 中修复。）

f:     # GCC4.1 -O3
        movl    -4(%rsp), %eax
        ret

f:    # GCC4.1 -O3 -fno-strict-aliasing
        movss   %xmm0, -4(%rsp)
        movl    -4(%rsp), %eax
        ret

即使旧的 GCC 版本也会发出警告 warning: dereferencing type -双关语指针将破坏严格别名规则，这应该表明 GCC 注意到了这一点，并且不认为它定义良好。后来选择支持此代码的 GCC 仍然发出警告。

有时在简单的情况下工作，但有时会崩溃，还是总是失败，这是否更好，这是有争议的。但鉴于 GCC -Wall 仍然对此发出警告，这可能是处理遗留代码或从 MSVC 移植的人们的便利性之间的一个很好的权衡。另一种选择是始终打破它，除非人们使用 -fno-strict-aliasing ，如果处理依赖于此行为的代码库，他们应该这样做。

---

成为 UB 并不意味着必须失败，

恰恰相反；例如，要真正捕获 C 抽象机中的每个有符号溢出，需要大量额外的工作，尤其是在将 2 + c - 3 等内容优化为 c - 1。这就是 gcc -fsanitize=undefined 尝试做的事情，在添加后添加 x86 jo 指令（除了它仍然进行常量传播，所以它只是添加 -1 code>，未检测到 INT_MAX 上的临时溢出。 noreferrer">https://godbolt.org/z/WM9jGT3ac）。而且严格别名似乎并不是它在运行时尝试检测的 UB 类型之一。

另请参阅 clang 博客文章： What Every C程序员应该了解未定义的行为

---

实现可以自由定义 ISO C 标准未定义的行为

例如，MSVC 总是定义这种别名行为，就像 GCC/clang/ICC 所做的那样-fno-strict-aliasing。当然，这并不能改变纯 ISO C 使其未定义的事实。

它只是意味着在那些特定的 C 实现上，代码保证按照您想要的方式工作，而不是偶然发生或通过事实上的编译器行为（如果它对于现代 GCC 来说足够简单）认识并做更“友好”的事情。

就像用于有符号整数溢出的 gcc -fwrapv 一样。

---

脚注 1：严格别名帮助代码生成的示例

#define QUALIFIER // restrict

void convert(float *QUALIFIER pf, const int *pi) {
    for(int i=0 ; i<10240 ; i++){
        pf[i] = pi[i];
    }
}

Godbolt 显示，使用 x86-64 的 GCC11.2 默认值 -O3，我们仅仅得到一个带有 < code>movdqu / cvtdq2ps / movups 和循环开销。使用 -O3 -fno-strict-aliasing ，我们可以获得两个版本的循环，并进行重叠检查以查看是否可以运行标量或 SIMD 版本。

是否存在严格别名有助于更好地生成代码的实际情况，而使用 restrict 无法实现相同的效果

您很可能有一个指针可能指向两个 int 数组中的任何一个，但绝对不在任何 float 变量上，因此您不能对其使用 restrict 。严格别名将使编译器仍然避免通过指针在存储周围溢出/重新加载 float 对象，即使 float 对象是全局变量或不能证明是本地的到函数。 （逃逸分析。）

或者一个struct node *，它绝对与树中的有效负载类型不同。

此外，大多数代码都不使用restrict。这可能会变得相当麻烦。不仅在循环中，而且在每个处理结构指针的函数中。如果你犯了错误并承诺了一些不真实的事情，那么你的代码就被破坏了。

Answer 3

该标准从来没有打算完全、准确、明确地划分已定义行为的程序和未定义行为的程序(*)，而是依赖编译器编写者运用一定的常识。

(*) 如果它是出于这个目的，那么它会惨败，正如由此产生的大量混乱所证明的那样。

考虑以下两个代码片段：

/* Assume suitable declarations of u are available everywhere */
union test { uint32_t ww[4]; float ff[4]; } u;

/* Snippet #1 */
uint32_t proc1(int i, int j)
{
  u.ww[i] = 1;
  u.ff[j] = 2.0f;
  return u.ww[i];
}

/* Snippet #2, part 1, in one compilation unit */
uint32_t proc2a(uint32_t *p1, float *p2)
{
  *p1 = 1;
  *p2 = 2.0f;
  return *p1;
}

/* Snippet #2, part 2, in another compilation unit */
uint32_t proc2(int i, int j)
{
  return proc2a(u.ww+i, u.ff+j);
}

很明显，该标准的作者希望在有意义的平台上对代码的第一个版本进行有意义的处理，但也很明显，至少 C99 及更高版本的一些作者版本并不打算要求第二个版本以同样的方式处理（C89 的一些作者可能希望“严格别名规则”仅适用于通过以下方式访问直接命名对象的情况另一种类型的指针，如图已发表的基本原理中给出的例子；基本原理中没有任何内容表明希望更广泛地应用它）。

另一方面，标准定义了 [] 运算符，使得 proc1 在语义上等同于：

uint32_t proc3(int i, int j)
{
  *(u.ww+i) = 1;
  *(u.ff+j) = 2.0f;
  return *(u.ww+i);
}

并且标准中没有任何内容暗示 proc()不应该具有相同的语义。 gcc 和 clang 似乎所做的是将 [] 运算符特殊化为与指针取消引用具有不同的含义，但标准中没有任何内容做出这样的区别。一致地解释标准的唯一方法是认识到带有 [] 的表单属于标准不要求实现有意义地处理但无论如何都依赖于它们来处理的操作类别。

像您的使用直接转换指针来访问与原始指针类型的对象关联的存储的示例的构造属于类似的构造类别，至少标准的一些作者可能期望（并且会要求，如果他们不这样做的话）不管有没有授权，编译器都会可靠地处理，因为没有可以想象的理由为什么高质量的编译器会这样做。然而，从那时起，clang 和 gcc 的发展就打破了这样的期望。即使 clang 和 gcc 通常会为函数生成有用的机器代码，它们也会寻求执行积极的过程间优化，从而无法预测哪些构造将 100% 可靠。与某些编译器不同，除非能够证明它们是合理的，否则不会应用潜在的优化转换，clang 和 gcc 寻求执行无法证明会影响程序行为的转换。