以下C联合访问模式是否为未定义行为? [英] Is the following C union access pattern undefined behavior?

问题描述

以下不是现代C语言中未定义的行为:

The following is not undefined behavior in modern C:

union foo
{
    int i;
    float f;
};
union foo bar;
bar.f = 1.0f;
printf("%08x\n", bar.i);

并打印1.0f的十六进制表示形式.

and prints the hex representation of 1.0f.

但是以下是未定义的行为:

However the following is undefined behavior:

int x;
printf("%08x\n", x);

那呢?

union xyzzy
{
    char c;
    int i;
};
union xyzzy plugh;

这应该是未定义的行为，因为尚未写入plugh的成员.

This ought to be undefined behavior since no member of plugh has been written.

printf("%08x\n", plugh.i);

但是这呢.这是未定义的行为吗?

But what about this. Is this undefined behavior or not?

plugh.c = 'A';
printf("%08x\n", plugh.i);

当今大多数C编译器将具有sizeof(char) < sizeof(int)，而sizeof(int)是2或4.这意味着在这种情况下，最多将写入plugh.i的50％或25％，但是要阅读剩余字节将读取未初始化的数据，因此应为未定义的行为.基于此，整个读取的行为是否不确定?

Most C compilers nowadays will have sizeof(char) < sizeof(int), with sizeof(int) being either 2 or 4. That means that in these cases, at most 50% or 25% of plugh.i will have been written to, but reading the remaining bytes will be reading uninitialized data, and hence should be undefined behavior. On the basis of this, is the entire read undefined behavior?

推荐答案

对此进行了介绍，并告诉我们，如果存在陷阱表示，则存在未定义的行为.

Defect report 283: Accessing a non-current union member ("type punning") covers this and tells us there is undefined behavior if there is trap representation.

缺陷报告问:

在与6.5.2.3#5相对应的段落中，C89包含此内容 句子:

In the paragraph corresponding to 6.5.2.3#5, C89 contained this sentence:

除了一个例外，如果在将值存储到对象的其他成员之后访问并集对象的成员，则 行为是由实现定义的.

With one exception, if a member of a union object is accessed after a value has been stored in a different member of the object, the behavior is implementation-defined.

与该句子相关的是这个脚注:

Associated with that sentence was this footnote:

标量类型的字节顺序"对于不沉迷于punning类型的隔离程序是不可见的(例如，通过 分配给工会的一名成员并通过以下方式检查存储 访问另一个成员，该成员是一个适当的Sixed数组 字符类型)，但必须符合 外部施加的存储布局.

The "byte orders" for scalar types are invisible to isolated programs that do not indulge in type punning (for example, by assigning to one member of a union and inspecting the storage by accessing another member that is an appropriately sixed array of character type), but must be accounted for when conforming to externally imposed storage layouts.

C99中唯一对应的词是6.2.6.1# 7 :

当值存储在并集类型的对象的成员中时，与该对象表示形式不符的对象表示形式的字节 成员，但对应于其他成员，但未指定值， 联合对象的值不应因此成为陷阱 表示.

When a value is stored in a member of an object of union type, the bytes of the object representation that do not correspond to that member but do correspond to other members take unspecified values, but the value of the union object shall not thereby become a trap representation.

目前尚不清楚C99单词是否具有相同的含义 暗示为C89字.

It is not perfectly clear that the C99 words have the same implications as the C89 words.

缺陷报告添加了以下脚注:

The defect report added the following footnote:

在6.5.2.3#3中的命名成员"一词上添加新的脚注78a:

Attach a new footnote 78a to the words "named member" in 6.5.2.3#3:

78a 如果用于访问并集对象内容的成员与上次用于在对象中存储值的成员不同，则按照6.2.6中的描述(一种有时称为类型调整"的过程)将新对象"重新解释为新类型的对象表示形式. 这可能是陷阱的表示形式.

78a If the member used to access the contents of a union object is not the same as the member last used to store a value in the object, the appropriate part of the object representation of the value is reinterpreted as an object representation in the new type as described in 6.2.6 (a process sometimes called "type punning"). This might be a trap representation.

C11 6.2.6.1常规告诉我们:

某些对象表示形式不必表示对象类型的值.如果对象的存储值具有这种表示形式，并且由不具有字符类型的左值表达式读取，则行为未定义. ⁵⁰⁾ 这样的表示形式称为陷阱表示. >

Certain object representations need not represent a value of the object type. If the stored value of an object has such a representation and is read by an lvalue expression that does not have character type, the behavior is undefined. If such a representation is produced by a side effect that modifies all or any part of the object by an lvalue expression that does not have character type, the behavior is undefined.⁵⁰⁾ Such a representation is called a trap representation.

这篇关于以下C联合访问模式是否为未定义行为?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！