C 联合类型双关数组

Question

鉴于以下代码，我有一些与类型双关相关的问题。我看不出这没有违反严格的别名规则，但我无法指出具体的违规行为。我最好的猜测是，将联合成员传递到函数中违反了严格的别名。

以下代码位于编译器资源管理器上。

#include <stdint.h>

union my_type
{
    uint8_t m8[8];
    uint16_t m16[4];
    uint32_t m32[2];
    uint64_t m64;
};

int func(uint16_t *x, uint32_t *y)
{
    return *y += *x;
}

int main(int argc, char *argv[])
{
    union my_type mine = {.m64 = 1234567890};
    return func(mine.m16, mine.m32);
}

我的观察：

• 假设 func 的参数不互相别名，则 func 不违反严格别名。
• 在 C 中，允许使用union 进行类型双关。
• 将 m16 和 m32 传递到 func 必须违反某些规定。

我的问题：

• 像这样的数组类型双关有效吗？
• 我通过将指针传递给 func 到底违反了什么？
• 在这个例子中我还遗漏了哪些其他问题？

Answer 1

违反的规则是 C 2018 6.5.16.1 3：

如果从与第一个对象的存储以任何方式重叠的另一个对象读取存储在对象中的值，则重叠应是精确的，并且两个对象应具有兼容类型的合格或不合格版本；否则，行为未定义。

具体来说，在*y += *x中，存储在y指向的对象mine.m16中的值是从另一个对象 mine.m32 与 mine.m16 的存储重叠，但重叠并不精确，而且无论限定符如何，这些对象也不具有兼容的类型。

请注意，此规则适用于简单分配，如 E1 = E2 中所示，而代码具有组件分配，E1 += E2。然而，复合赋值 E1 += E2 在 6.5.16.2 3 中定义为等价于 E1 = E1 + E2，除了左值 E1 > 仅评估一次。

像这样的数组的类型双关有效吗？

是的，C 标准允许通过联合成员使用别名；读取最后存储的成员以外的成员将重新解释新类型中的字节。然而，如果程序的行为是由 C 标准定义的，特别是上面引用的规则，这并不能免除程序遵守其他规则的责任。

将指针传递给 func 到底违反了什么？

传递指针不会违反任何规则。正如上面所回答的，使用指针的赋值违反了规则。

在此示例中我还缺少哪些其他问题？

如果我们更改 func:

int func(uint16_t *x, uint32_t *y)
{
    *y += 1;
    *x += 1;
    return *y;
}

则 6.5.16.1 3 中的规则不适用，因为不存在涉及重叠对象的赋值。并且不违反 6.5 7 中的别名规则，因为 *y 是一个定义为用于访问它的类型的对象，uint16_t 和 *x 是一个对象，定义为用于访问它的类型，uint32_t。然而，如果这个函数被单独翻译（没有可见的union定义），编译器可以假设*x和*y执行不重叠，因此它可能会缓存由 *y += 1; 生成的 *y 值并返回该缓存值，而忽略 * x += 1; 变化<代码>*y。这是C标准的一个缺陷。

Answer 2

将 m16 和 m32 传递给 func 必须违反某些规定。

func(uint16_t *x, uint32_t *y) 可以自由地假设 *x 和 *y 不重叠，因为 x, y 是足够不同的指针类型。由于引用的数据在OP的代码中确实重叠，所以我们遇到了问题。

有关 union 和别名的特殊问题在 func() 主体中不适用，因为调用代码的union-ness 是丢失的。

替代的“安全”代码可能是：

// Use volatile to prevent folding these 2 lines of code.
// The key is that even with optimized code, 
// the sum must be done before *y assignment.
volatile uint32_t sum = *y + *x;
*y = sum;

return (int) (*y);

---

将指针传递给 func 到底违反了什么？

将指针传递给函数 func() 不必考虑的重叠数据。

---

像这样的数组的类型双关有效吗？

我不认为这是一个数组或联合问题，只是将指针传递给函数 func() 没有义务考虑的重叠数据之一。

在此示例中我还缺少哪些其他问题？

次要问题：int 可能是 16 位，可能会导致在 uint32_t 到 int 转换中出现实现定义的行为。

---

考虑 fun1() 之间的差异

uint32_t fun1(uint32_t *a, uint32_t *b);
uint32_t fun2(uint32_t * restrict a, uint32_t * restrict b);

就必须考虑重叠的可能性。 fun2() 不会。

Answer 3

我的观察：

• 假设 func 的参数不互相别名，func 不会违反严格别名。

不可靠。所谓的严格别名规则是根据用于访问给定对象的左值（相对于该对象的有效类型）来表达的。 func() 的两个参数不需要互相别名来执行 func() 来产生严格别名冲突。示例：

uint32_t x = 0, y = 1;
func((uint16_t *)&x, &y);
// func will violate strict aliasing when it dereferences its first parameter

围绕函数参数相互别名的问题将属于您没有使用的 restrict 限定指针的范围。

---

• 在 C 语言中，允许使用联合进行类型双关。

是的，只要双关是通过 union 对象执行的。 C17 6.5/7（上述严格别名规则）涵盖了这一点：

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

[...]

• 在其成员中包含上述类型之一的聚合或联合类型

请注意，这与被访问的存储实际上是在联合对象内部，而是关于用于访问它的左值类型相对于被访问对象的实际（有效）类型。

---

• 将 m16 和 m32 传递给 func 必须违反某些规定。

确实如此，尽管语言规范可能比实际情况更清楚。然而，它确实说：

任何时候最多可以将一个成员的值存储在联合对象中。

(C17 6.7.2.1/16)

在您的特定示例中， mine.m16 和 mine.m32 都没有调用时存储在其中的值，但在任何情况下，最多其中一个可以有值。当 func 尝试读取存储在这些对象中的值时，结果未定义（因为它们实际上没有存储值）。

规范中包含的第 6.5.2.3/6 段支持了这种解释：

为了简化联合的使用，做出了一项特殊保证：
如果联合包含多个共享共同首字母的结构
序列（见下文），并且如果联合对象当前包含一个
这些结构中，允许检查共同的初始
其中任何一个完整类型声明的一部分
工会的成员是可见的。

如果通常可以访问随机联合成员，而不管哪个成员实际上存储了值，则不需要这样的特殊规定。

---

我的问题：

• 像这样的数组类型双关有效吗？

不是那样的，不。规范允许的数组类型双关还有其他变体。

---

• 将指针传递给 func 到底违反了什么？

调用本身并没有违反任何内容。获取联合成员的地址是合法的，即使当前没有存储值，并且将结果指针值传递给函数也是合法的。但是，当使用这些参数调用时，函数在尝试取消引用一个或两个指针时会犯严格别名冲突，如上所述。

---

• 在此示例中我还缺少哪些其他问题？

与您的其他答案之一相反，所提供的代码并不违反第 6.5.16.1/3 段。存储在 *y 中的值不是从重叠对象 *x 读取的，而是该值与原始值的总和<代码>*y。该总和是计算得出的，而不是从对象中读取的，因此 6.5.16.1/3 不适用。但您可能会忽略，如果 func() 执行简单的赋值而不是加号，就会违反 6.5.16.1/3。