在我们的讲座中,我们讨论了 std::list
的内部可能实现。讲师展示了创建虚拟节点以指示列表末尾的方法:
struct Node { Node* prev; ... }
Node* dummy = reinterpret_cast<Node*>(new int8_t[sizeof(Node)]);
dummy->prev = ... /* last node */;
他们声称最后一行可能导致未定义的行为。我不明白为什么这可能不安全。归根结底,我们只是在不取消引用预设的情况下覆盖了几位。如果这真的是个问题,它不会在 reinterpret_cast
ing 时发生吗?
那么,这里是否真的发生了未定义的行为,如果是,为什么?
最佳答案
首先,对于你的第二行
Node* dummy = reinterpret_cast<Node*>(new int8_t[sizeof(Node)]);
自己。
new
返回指向它创建的 int8_t
对象数组中第一个 int8_t
对象的指针。
reinterpret_cast
的行为取决于指针所代表地址的对齐方式。如果它适合 Node
类型的对象对齐,那么它将保持指针值不变(因为在指针可相互转换的位置明确没有 Node
对象使用 int8_t
对象)。如果未适当对齐,则返回的指针值将未指定。
未指定 意味着我们不知道该值是什么,但它不会导致未定义的行为。
因此,在任何情况下,第二行和转换本身都没有未定义的行为。
线
dummy->prev = ... /* last node */;
要求dummy
指向的对象实际上是一个Node
对象。否则它有未定义的行为。如上所述,reinterpret_cast
为我们提供了一个未指定的值或指向 int8_t
对象的指针。这已经是一个问题,我认为至少需要一个 std::launder
调用。
即使 new
返回的指针正确对齐,我们仍然需要检查是否存在 Node
对象。我们当然没有在任何显示的操作中显式创建任何此类对象,但是隐式对象创建可能会有所帮助(至少从 C++20 开始,但我想这应该是针对旧标准版本的缺陷报告).
具体来说,可以在unsigned char
、std::byte
和char
类型数组中隐式创建对象,但有一些限制( CWG 2489 ) 当数组的生命周期开始时。 int8_t
通常是 signed char
我认为不允许是前面提到的三种类型中的任何一种(参见例如 this question )。这消除了 UB 的唯一可能出路。
所以你的第三行代码确实有未定义的行为。
即使您通过将类型形式 int8_t
更改为 std::byte
来解决此问题,Node
的细节上还有其他限制使隐式对象创建成为可能。可能还需要添加 std::launder
调用。
所有这些还没有考虑对齐,因为虽然 new[]
获得内存有一些对齐要求,但我认为标准要求 new[]
本身仅针对 char
、unsigned char
和 std::byte
数组 new< 返回比元素类型所需的对齐更强的指针
.
许多这些问题可能可以通过使用例如直接使用 operator new
,可能会提供对齐请求,并确保 Node
是一个聚合。
在任何情况下,编写这样的代码都是非常冒险的,因为很难确定它不是 UB。应尽可能避免。
关于c++ - reinterpret_cast 从原始内存中获取的指针重新分配是否会导致 UB?,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/70880512/