这意味着使用union是一种符合标准的方法，可以避免类型双关语和严格的别名冲突，如果试图通过不同类型的指针访问存储值，则会发生这种情况。
以unsigned和float为例，通常都是32位，在某些情况下可能需要查看unsigned*或float*中的存储值。

float f = 3.3;
    // unsigned u = *(unsigned *)&f;  /* violation */

在6.5（p7）之后，您可以在两种类型之间使用union，并访问与unsigned或float相同的信息，而无需类型双关指针或违反严格的别名规则。

typedef union {
    float f;
    unsigned u;
} f2u;
...    
    float f = 3.3;
    // unsigned u = *(unsigned *)&f;  /* violation */
    f2u fu = { .f = f };
    unsigned u = fu.u;                /* OK - no violation */

所以严格别名规则防止通过另一个类型的指针访问有效类型的内存，除非该指针是char类型或者指向两个类型之间的联合成员。
（**注意：**标准的这一节绝不是一个清晰的例子。（你可以读10遍，仍然会挠头）它的意图是抑制指针类型的滥用，同时仍然认识到任何形式的内存块都必须能够通过字符类型访问，（union是其他允许的访问方式之一）。
在过去的几年里，编译器在标记违反规则的行为方面做得更好。

要点有两个目的：首先，如果我们认识到，对一个左值的访问是或可能是基于一个特定类型的左值的，那么它应该被识别为后一种类型的左值或可能的左值，然后给出如下的内容：

union U {int x[10]; float y[10];} u;

一个从u派生出来的左值可以访问其中包含的所有对象。一个实现可以识别出一个左值基于另一个左值的情况是一个实现质量问题，一些高质量的编译器，比如icc，可以识别出这样的情况：

int load_array_element(int *array, int i) { return array[i]); }
...
int test(int i) { return load_array_element(&u.x, i); }

对load_array_element的 * special * 调用可能对*array执行的任何操作都将对u执行（毕竟，它被赋予了直接从u形成的左值的地址），而其他编译器（如Clang和gcc）甚至无法将*(u.x+i)这样的结构识别为基于u的左值。
这个项目符号的第二个目的是建议，即使编译器太原始而无法跟踪直线代码中的左值派生，它也应该识别给定的声明：

int *p,i;
struct foo { int x;} foo;

如果它看到*p=1; i=foo.x;而没有注意到p来自哪里，则它必须确保在读取foo.x之前执行对*p的写入。即使这仅在已经费心注意的编译器能够看到p是从foo形成的情况下才真正必要，与使对foo.x的访问强制完成对整数指针的目标的任何未决写入相比，以那些术语描述事物将增加明显的编译器复杂性。
注意，如果只对通过新派生指针访问结构体或联合体成员感兴趣，则不需要包含通过成员类型的左值访问结构体或联合体对象的一般权限。foo.x = 1; p = &foo.x; i=*p;，则获取foo.x地址的操作应使编译器在运行可能使用该地址的任何代码之前完成对foo.x的任何挂起写入（不知道下游代码将如何处理该地址的编译器可以简单地立即完成写入）。如果代码序列是foo.x = 1; i = *p;，经由左值foo访问foo.x的动作将意味着可能标识该存储的任何现有指针将是“陈旧的”，因此编译器将没有义务识别这样的指针可能标识与foo.x相同的存储。
注意，尽管脚注88清楚地说明了“严格别名规则”的目的是指定何时允许对象别名，gcc和clang的解释将该规则解释为忽略对象由左值访问的情况的借口，而左值显然是从对象派生的。也许回想起来，标准的作者应该包括一个规定“请注意，这条规则并没有试图禁止低质量编译器以迟钝的方式行事，但也不是要鼓励这种行为”，但C89的作者没有理由期望这条规则会被解释为它所做的，而clang和gcc的作者几乎肯定会否决任何现在添加这种语言的建议。