使用char *访问int可能具有未定义的行为吗? [英] Does accessing an int with a char * potentially have undefined behavior?

问题描述

以下用于测试字节序的代码应具有实现定义的行为:

The code below for testing endianness is expected to have implementation defined behavior:

int is_little_endian(void) {
    int x = 1;
    char *p = (char*)&x;
    return *p == 1;
}

但是在故意设计的架构上，它可能具有未定义的行为吗?例如，值1(或另一个选择好的值)的int表示形式的第一个字节可以是char类型的陷阱值吗?

But is it possible that it may have undefined behavior on purposely contrived architectures? For example could the first byte of the representation of an int with value 1 (or another well chosen value) be a trap value for the char type?

如注释中所述，类型unsigned char将不会出现此问题，因为它不能具有陷阱值，但是此问题专门涉及char类型.

As noted in comments, the type unsigned char would not have this issue as it cannot have trap values, but this question specifically concerns the char type.

推荐答案

每C 2018 6.2.5 15，char表现为signed char或unsigned char.假设它是signed char. 6.2.6.2 2讨论有符号整数类型，包括signed char.在本段末尾，它说:

Per C 2018 6.2.5 15, char behaves as either signed char or unsigned char. Suppose it is signed char. 6.2.6.2 2 discusses signed integer types, including signed char. At the end of this paragraph, it says:

这些[的符号和大小，二的补码或一个的补码]中的哪些适用于实现定义，符号位1和所有值位均为零(对于前两个)或符号位和所有值位均为1(对1的补码)的值是陷阱表示形式或正常值.

Which of these [sign and magnitude, two’s complement, or ones’ complement] applies is implementation-defined, as is whether the value with sign bit 1 and all value bits zero (for the first two), or with sign bit and all value bits 1 (for ones’ complement), is a trap representation or a normal value.

因此，本段允许signed char具有陷阱表示.但是，该标准中的段落表示访问陷阱表示形式可能具有未定义的行为，即6.2.6.1 5，专门排除了字符类型:

Thus, this paragraph allows signed char to have a trap representation. However, the paragraph in the standard that says accessing trap representations may have undefined behavior, 6.2.6.1 5, specifically excludes character types:

某些对象表示形式不必表示对象类型的值.如果对象的存储值具有这种表示形式，并且由不具有字符类型的左值表达式读取，则该行为是不确定的.如果这种表示是由副作用产生的，该副作用通过不具有字符类型的左值表达式修改对象的全部或任何部分，则该行为是不确定的.这种表示形式称为陷阱表示形式.

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.

因此，尽管char可能具有陷阱表示，但是没有理由我们不应该访问它.那么就有一个问题，如果我们在表达式中使用该值会发生什么?如果char具有陷阱表示，则它不表示值.因此，尝试将它与*p == 1中的1比较似乎没有定义的行为.

Thus, although char may have trap representations, there is no reason we should not be able to access it. There is then the question of what happens if we use the value in an expression? If a char has a trap representation, it does not represent a value. So attempting to compare it to 1 in *p == 1 does not seem to have a defined behavior.

对于任何普通的C实现，int中1的特定值都不会在char中导致陷阱表示，因为1将位于该字节某个字节的最右"(最低值)位. int，并且没有常规的C实现将char的符号位放置在该位置的位中.但是，C标准显然不禁止这种安排，因此，从理论上讲，值1的int可能在其字节之一中用位00000001进行编码，并且这些位可能是char的陷阱表示.

The specific value of 1 in an int will not result in a trap representation in char for any normal C implementation, as the 1 will be in the "rightmost" (lowest valued) bit of some byte of the int, and no normal C implementation puts the sign bit of a char in the bit in that position. However, the C standard apparently does not prohibit such an arrangement, so, theoretically, an int with value 1 might be encoded with bits 00000001 in one of its bytes, and those bits might be a trap representation for a char.

这篇关于使用char *访问int可能具有未定义的行为吗?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！