c - 陷阱表示、unsigned char 和 IA64 NaT

Question

Source:Uninitialized garbage on ia64 can be deadly

On the ia64, each 64-bit register is actually 65 bits. The extra bit is called "NaT" which stands for "not a thing". The bit is set when the register does not contain a valid value. Think of it as the integer version of the floating point NaN.

The NaT bit gets set most commonly from speculative execution. There is a special form of load instruction on the ia64 which attempts to load the value from memory, but if the load fails (because the memory is paged out or the address is invalid), then instead of raising a page fault, all that happens is that NaT bit gets set, and execution continues.

All mathematical operations on NaT just produce NaT again.

源文章继续解释寄存器如何在推测加载期间最终具有 NaT 表示，并做出以下评论:

For you see, if you have a register whose value is NaT and you so much as breathe on it the wrong way (for example, try to save its value to memory), the processor will raise a STATUS_REG_NAT_CONSUMPTION exception.

从其他对 Trap 表示的堆栈溢出答案看来，
“任何类型(unsigned char 除外)都可能有陷阱表示”。

这link说是

The only guarantees the standard gives about accessing uninitialized data are that the unsigned char type has no trap representations, and that padding has no trap representations.

如果这样一个寄存器(设置了 NaT 位的寄存器)被分配用于存储未初始化的 unsigned char(类似于下面缺陷报告中的代码片段)，根据 ISO C11 如何处理？

下面的缺陷报告是否指向相同的问题，是否已在 ISO C11 中得到纠正？

如果不是这种特殊情况如何处理？

If the lvalue designates an object of automatic storage duration that could have been declared with register storage class (never had its address taken), and that object is uninitialized (not declared with an initializer, and no assignment to it has been performed prior to the use), the behavior is undefined

在“C1X 的更改”部分的缺陷报告末尾添加的上述内容是否处理了这种情况？

defect_report

The following function has undefined behavior under C90, but appears to be strictly conforming under C99

  int foo(void) {
      unsigned char uc;
      return uc + 1 >= 0;
  }

Answer 1

首先，如果您还没有亲眼看到，可以从here 获取C11 标准的最终草案。 (see also)。

来自 DR 的文本确实被添加到第 6.3.2.1 p2 节，这使得代码片段根据 C11 未定义。

标准中有关陷阱表示的部分继续排除 unsigned char 可以具有陷阱表示的可能性 - 但这并不重要。这里要注意的是，正如 2008 年 Spring DR 中提到的那样，从标准的角度来看，这实际上根本不需要涉及陷阱表示本身(它们只是 UB 可能导致你在金属上的问题)。问题实际上是关于未初始化的自动值；修改后的段落通过澄清 unsigned char 应该不仅仅因为其类型的一个而被视为免除一般类型的 UB 来解决这个问题-特定属性(不是通过增加该属性的复杂性)。

您可以想象，正如 NaT 位是 IA64 上整数的实现细节一样，没有陷阱表示是一般 C 类型家族中一种特定类型的“实现细节”。变量的实际类型次于更一般的规则，即您不应该安全地访问任何未初始化的变量；添加阐明了优先级。