如何在不违反类型别名规则的情况下解释消息负载？

Question

我的程序通过网络接收消息。这些消息被一些中间件反序列化（即我无​​法更改的其他人的代码）。我的程序接收到如下所示的对象：

struct Message {
    int msg_type;
    std::vector<uint8_t> payload;
};

通过检查msg_type，我可以确定消息负载实际上是一个uint16_t 值数组。我想在没有不必要的副本的情况下读取该数组。

我的第一个想法是这样做：

const uint16_t* a = reinterpret_cast<uint16_t*>(msg.payload.data());

但是从a 读取似乎违反了标准。这是第 3.10.10 条：

如果程序尝试通过以下类型之一以外的左值访问对象的存储值，则行为未定义：

• 对象的动态类型，
• 对象动态类型的 cv 限定版本，
• 与对象的动态类型类似（如 4.4 中定义）的类型，
• 对应于对象动态类型的有符号或无符号类型，
• 一种有符号或无符号类型，对应于对象动态类型的 cv 限定版本，
• 一种聚合或联合类型，在其元素或非静态数据成员（递归地包括子聚合或包含联合的元素或非静态数据成员）中包含上述类型之一，
• 一种类型，它是对象动态类型的（可能是 cv 限定的）基类类型，
• char 或 unsigned char 类型。

在这种情况下，a 将是泛左值，uint16_t* 似乎不符合任何列出的条件。

那么如何将有效负载视为uint16_t 值的数组而不调用未定义的行为或执行不必要的复制？

Answer 1

如果您要一个一个地使用这些值，那么您可以memcpy 到uint16_t，或写payload[0] + 0x100 * payload[1] 等，至于您想要哪种行为。这不会是“低效的”。

如果你必须调用一个只接受uint16_t 数组的函数，并且你不能更改传递Message 的结构体，那么你就不走运了。在标准 C++ 中，您必须制作副本。

如果您使用 gcc 或 clang，另一种选择是在编译相关代码时设置 -fno-strict-aliasing。

Answer 2

如果你想在没有UB的情况下严格遵循C++标准，并且不使用非标准的编译器扩展，你可以尝试：

uint16_t getMessageAt(const Message& msg, size_t i) {
   uint16_t tmp;
   memcpy(&tmp, msg.payload.data() + 2 * i, 2);
   return tmp;
}

编译器优化应该避免memcpy在生成的机器码中复制到这里；参见，例如，Type Punning, Strict Aliasing, and Optimization。

事实上，复制到返回值，但取决于你将如何处理它，这个副本也可以被优化掉（例如，这个值可以被加载到一个寄存器中并只在那里使用）。

Answer 3

如果你想严格正确，正如你引用的标准所说，你不能。 如果您想明确定义行为，则需要制作副本。

如果代码是可移植的，您将需要以任何一种方式处理字节顺序，并从各个 uint8_t 字节重构您的 uint16_t 值，根据定义，这需要一个副本。

如果你真的知道你在做什么，你可以忽略标准，只做你描述的 reinterpret_cast 。

GCC 和 clang 支持-fno-strict-aliasing 以防止优化生成损坏的代码。 据我所知，在撰写本文时，Visual Studio 编译器没有标志，并且从不执​​行此类优化 - 除非您使用 declspec(restrict) 或 __restrict。

Answer 4

如果 vector 数据是这样构建的，您的代码可能不是 UB（或边界线，取决于读者的感受）：

Message make_array_message(uint16_t* x, size_t n){
 Message m;
 m.type = types::uint16_t_array;
 m.payload.reserve(sizeof(uint16_t)*n);
 std::copy(x,x+n,reinterpret_cast<uint16_t*>(m.payload.data()));
 return m;
 }

在这段代码中，向量的数据包含uint16_t 的序列，即使它被声明为uint8_t。所以使用这个指针访问数据：

const uint16_t* a = reinterpret_cast<uint16_t*>(msg.payload.data());

完全没问题。但是以uint8_t 的身份访问vector 的数据将是UB。访问 a[1] 将适用于所有编译器，但在当前标准中它是 UB。这可以说是标准中的一个缺陷，c++ 标准化委员会正在努力修复它，请参阅P0593 Implicit object creation for low level object manipulation。

到目前为止，在我自己的代码中，我不处理标准中的缺陷，我更喜欢遵循编译器的行为，因为对于这个主题，这是制定规则的编码器和编译器，标准只会遵循！