c++ - 签名/未签名别名规则是否按预期工作？

Question

这是 C++17 形式的规则 ([basic.lval]/8)，但它在其他标准中看起来很相似(在 C++98 中是“lvalue”而不是“glvalue”):

8 If a program attempts to access the stored value of an object through a glvalue of other than one of the following types the behavior is undefined:

(8.4) — a type that is the signed or unsigned type corresponding to the dynamic type of the object

这条规则听起来像是“除非你做了 X，否则你会得到 UB”，但这并不意味着如果你做了 X，你就不会像人们预期的那样得到 UB!实际上，执行 X 是有条件或无条件 UB，具体取决于标准的版本。

让我们看下面的代码:

int i = -1;
unsigned j = reinterpret_cast<unsigned&>(i);

这段代码的行为是什么？

C++98 和 C++11

[expr.reinterpret.cast]/10(C++11 中的/11)(重点是我的):

An lvalue expression of type T1 can be cast to the type “reference to T2” if an expression of type “pointer to T1” can be explicitly converted to the type “pointer to T2” using a reinterpret_cast. That is, a reference cast reinterpret_cast(x) has the same effect as the conversion *reinterpret_cast(&x) with the built-in & and * operators. The result is an lvalue that refers to the same object as the source lvalue, but with a different type.

所以 reinterpret_cast<unsigned&>(i)左值指的是 int对象 i , 但带有 usigned类型。初始化需要初始化表达式的值，这正式意味着将左值到右值转换应用于左值。

[conv.lval]/1:

An lvalue of a non-function, non-array type T can be converted to an rvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If the object to which the lvalue refers is not an object of type T and is not an object of a type derived from T, or if the object is uninitialized, a program that necessitates this conversion has undefined behavior.

我们的左值 unsigned类型未引用 unsigned 的对象type 这意味着行为是未定义的。

C++14 和 C++17

在这些标准中，情况有点复杂，但规则略有放宽。 [expr.reinterpret.cast]/11 告诉同样的:

The result refers to the same object as the source glvalue, but with the specified type.

有关 UB 的冒犯性措辞已从 [conv.lval]/1 中删除:

A glvalue of a non-function, non-array type T can be converted to a prvalue. If T is an incomplete type, a program that necessitates this conversion is ill-formed. If T is a non-class type, the type of the prvalue is the cv-unqualified version of T. Otherwise, the type of the prvalue is T.

但是 L-to-R 转换读取的是哪个值？ [conv.lval]/(2.6)(C++17 中的/(3.4))回答了这个问题:

… the value contained in the object indicated by the glvalue is the prvalue result

unsigned左值 reinterpret_cast<unsigned&>(i)表示 i int值为 -1 的对象L-to-R 转换产生的纯右值有 unsigned类型。 [expr]/4 说:

If during the evaluation of an expression, the result is not mathematically defined or not in the range of representable values for its type, the behavior is undefined.

-1绝对不在 unsigned 的可表示值范围内纯右值表达式的类型，因此行为未定义。

如果 i 将定义行为对象包含 [0, INT_MAX] 范围内的值。

同样的推理也适用于 unsigned 的情况。通过 int 访问对象增值。这是 C++98 和 C++11 中的 UB 以及 C++14 和 C++17 中的 UB，除非对象的值在 [0, INT_MAX] 范围内。

因此，与普遍认为此别名规则允许将对象重新解释为包含相应有符号/无符号类型的值的看法相反，它不允许这样做。对于[0, INT_MAX]范围内的值，有符号和无符号类型的对象具有相同的表示("有符号整数类型的非负值范围是对应无符号整数类型的子范围，表示两种类型中相同值的值是相同的”，[basic.fundamental]/3 in C++17)。很难将这种访问称为“重新解释”，更不用说这是 C++14 之前的无条件 UB。

那么规则 ([basic.lval]/(8.4)) 的目的是什么？

Answer 1

这是 defect report 2214 的主题，它说:

Section: 6.9.1 [basic.fundamental] Status: C++17 Submitter: Richard Smith Date: 2015-12-15

[Adopted at the February/March, 2017 meeting.]

According to 6.9.1 [basic.fundamental] paragraph 3,

The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the value representation of each corresponding signed/unsigned type shall be the same. (This is the wording in C++11 and C++14 versions, though the paragraph numbers may be different -- n.m.)

C11对应的写法是，

The range of nonnegative values of a signed integer type is a subrange of the corresponding unsigned integer type, and the representation of the same value in each type is the same.

C 的措辞可以说更清晰，但它失去了 C++ 措辞的暗示，即有符号类型的符号位是相应无符号类型的值表示的一部分。

提议的决议(2017 年 1 月):

将 6.9.1 [basic.fundamental] 第 3 段更改如下:

...The standard and extended unsigned integer types are collectively called unsigned integer types. The range of non-negative values of a signed integer type is a subrange of the corresponding unsigned integer type, the representation of the same value in each of the two types is the same, and the value representation of each corresponding signed/unsigned type shall be the same. The standard signed integer types...

所以这显然是一直以来的意图。 C++17 刚刚修正了措辞。

C 和 C++ 标准从未打算允许将负值重新解释为无符号，反之亦然。在野外有几种带符号的整数表示形式(例如一个的补码、二进制的补码、符号和大小)并且标准不强制其中任何一个，因此它不能规定这种重新解释的效果。它们可以已实现定义，但考虑到陷阱表示的可能性，这并没有真正的好处。 “实现定义的结果或陷阱”与“未定义”一样好。