每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.