我目前对严格别名规则背后的原理感到好奇。我知道在C语言中某些别名是不允许的，这是为了允许优化，但我很惊讶这是在标准定义时优先选择的解决方案，而不是跟踪类型转换。
因此，显然以下示例违反了严格别名规则：
uint64_t swap(uint64_t val)
{
uint64_t copy = val;
uint32_t *ptr = (uint32_t*)© // strict aliasing violation
uint32_t tmp = ptr[0];
ptr[0] = ptr[1];
ptr[1] = tmp;
return copy;
}
由于在这个例子中，所有代码都可以被编译器看到，因此编译器可以理论上确定请求的内容并生成所需的汇编代码。然而，演示一个不需要严格别名规则的情况并不能证明不存在其他需要它的情况。
考虑代码是否包含：
foo(&val, ptr)
如果声明 foo 为 void foo(uint64_t *a, uint32_t *b);，那么在 foo 内部，编译器无法知道 a 和 b 指向同一对象（的部分）。
接下来有两个选择：第一个是允许别名，这种情况下编译器不能依赖于 *a 和 *b 是不同的这一事实进行优化。例如，每次写入 *b 时，编译器必须生成汇编代码重新加载 *a，因为它可能已经改变了。不允许像保持一个寄存器中的 *a 副本这样的优化。
第二个选择是禁止别名（具体而言，不定义程序执行此类操作的行为）。在这种情况下，编译器可以依赖于 *a 和 *b 是不同的这一事实进行优化。
C 委员会选择了第二个选项，因为它提供更好的性能，同时不会过度限制程序员。
foo(&val, ptr)给出了两个指向同一对象的指针。然而，请考虑指针可能以各种方式计算。我预计，在翻译时（包括链接）确定两个指针是否可能指向同一对象的一般问题是不可计算的。（可能类似于停机问题：如果我们能够计算它，我们可以编写一个程序，只有在检查代码报告代码未通过相同地址时才传递相同地址。） - Eric Postpischil它允许编译器在不需要限定修饰符的情况下优化变量重新加载。
示例：
int f(long *L, short *S)
{
*L=42;
*S=43;
return *L;
}
int g(long *restrict L, short *restrict S)
{
*L=42;
*S=43;
return *L;
}
在x86_64上，使用了严格别名禁用的编译选项（gcc -O3 -fno-strict-aliasing）进行编译:
f:
movl $43, %eax
movq $42, (%rdi)
movw %ax, (%rsi)
movq (%rdi), %rax ; <<*L reloaded here cuz *S =43 might have changed it
ret
g:
movl $43, %eax
movq $42, (%rdi)
movw %ax, (%rsi)
movl $42, %eax ; <<42 constant-propagated from *L=42 because *S=43 cannot have changed it (because of `restrict`)
ret
使用 gcc -O3 编译（意味着 -fstrict-alising）在 x86_64 上：
f:
movl $43, %eax
movq $42, (%rdi)
movw %ax, (%rsi)
movl $42, %eax ; <<same as w/ restrict
ret
g:
movl $43, %eax
movq $42, (%rdi)
movw %ax, (%rsi)
movl $42, %eax
ret
float f(int *pi, float *pf) {
*pi = 1;
return *pf;
}
pi和pf持有相同的地址时，其中*pf旨在重新解释最近写入的*pi的位，被认为是不合理的，因此尊敬的委员会成员（以及C语言的设计者）认为要求编译器避免稍微复杂一些的示例中的常识程序转换是不合适的。float f(int *pi, double *pf) {
(*pi)++;
(*pf) *= 2.;
(*pi)++;
}
在这里，允许两个指针都指向同一个对象的特殊情况会使得合并增量的任何简化无效；假设不存在这样的别名可以使代码编译为：
float f(int *pi, double *pf) {
(*pf) *= 2.;
(*pi) += 2;
}
uint32_t*的访问都是在可见地从uint64_t派生出来的情况下进行的），最有可能的原因是标准的作者认识到，任何真正努力制作适用于低级编程的高质量实现的人都会支持像你这样的结构（作为“流行扩展”），无论标准是否规定。这个原则在处理像以下结构这样的结构时更明确地体现出来：unsigned mulMod65536(unsigned short x, unsigned short y)
{ return (x*y) & 65535u; }
volatile对象检索或通过整数转换产生的指针）应视为实现质量问题。虽然作者可以要求实现处理某些明显的情况，同时将其他情况留作QOI问题，但我认为他们没有考虑到实现者会将标准用作忽略明显情况的借口的想法。 - supercat
double或long，有严格对齐限制的系统需要将它们放在8字节边界上，否则你的进程可能会被类似SIGBUS的东西杀死。这并不是严格别名问题，但它涉及到许多相同的根本问题。 - Andrew Henleuint64_t根据定义几乎总是适合于uint32_t的对齐方式，所以这里肯定不是问题。 - Antti Haapala -- Слава Україні