char* 和 std::uint8_t* 之间的 reinterpret_cast - 安全吗？

Question

现在我们有时都必须使用二进制数据。在 C++ 中，我们使用字节序列，并且从一开始char 就是我们的构建块。定义为具有 1 的sizeof，它是字节。所有库 I/O 函数默认使用char。一切都很好，但总有一点问题，一些奇怪的问题困扰了一些人 - 一个字节中的位数是实现定义的。

所以在 C99 中，决定引入几个 typedef 来让开发人员轻松表达自己，固定宽度的整数类型。当然是可选的，因为我们不想损害可移植性。其中uint8_t作为std::uint8_t迁移到C++11，是一个固定宽度的8位无符号整数类型，对于真正想要使用8位字节的人来说是完美的选择。

因此，开发人员接受了新工具并开始构建库，以明确声明他们接受 8 位字节序列，如std::uint8_t*、std::vector<std::uint8_t> 或其他形式。

但是，也许经过深思熟虑，标准化委员会决定不要求实现std::char_traits<std::uint8_t>，因此禁止开发人员轻松便携地实例化std::basic_fstream<std::uint8_t>，并轻松将std::uint8_ts 读取为二进制数据。或者，我们中的一些人不关心字节中的位数并且对此感到满意。

但不幸的是，两个世界发生冲突，有时您必须将数据作为char* 并将其传递给需要std::uint8_t* 的库。但是等等，你说，char 不是可变位和std::uint8_t 固定为 8 吗？会不会导致数据丢失？

嗯，这有一个有趣的标准话。 char 定义为恰好保存一个字节，字节是内存的最低可寻址块，因此不能有位宽小于char 的类型。接下来，它被定义为能够保存 UTF-8 代码单元。这给了我们最小值 - 8 位。所以现在我们有一个需要 8 位宽的 typedef 和一个至少 8 位宽的类型。但是有替代品吗？是的，unsigned char。请记住，char 的签名是实现定义的。还有其他类型吗？谢天谢地，没有。所有其他整数类型都需要超出 8 位的范围。

最后，std::uint8_t 是可选的，这意味着如果未定义使用此类型的库将无法编译。但是如果它编译呢？我可以非常自信地说，这意味着我们在一个 8 位字节和CHAR_BIT == 8 的平台上。

一旦我们知道，我们有 8 位字节，std::uint8_t 被实现为 char 或 unsigned char，我们是否可以假设我们可以从 reinterpret_cast 执行 char* 到 @987654348 @ 反之亦然？便携吗？

这就是我的标准阅读能力让我失望的地方。我阅读了有关安全派生指针 ([basic.stc.dynamic.safety]) 的内容，据我了解，以下内容：

std::uint8_t* buffer = /* ... */ ;
char* buffer2 = reinterpret_cast<char*>(buffer);
std::uint8_t buffer3 = reinterpret_cast<std::uint8_t*>(buffer2);

如果我们不触摸buffer2 是安全的。如果我错了，请纠正我。

所以，给定以下先决条件：

• CHAR_BIT == 8
• std::uint8_t 已定义。

假设我们正在处理二进制数据并且char 可能缺少符号无关紧要，来回转换char* 和std::uint8_t* 是否可移植且安全？

我希望参考标准并附上解释。

编辑：谢谢，杰里·科芬。我将添加来自标准的引用（[basic.lval]，§3.10/10）：

如果一个程序试图通过 Glvalue 访问一个对象的存储值，而不是其中一个 以下类型的行为未定义：

...

— char 或 unsigned char 类型。

EDIT2：好的，更深入。 std::uint8_t 不保证是 unsigned char 的 typedef。它可以实现为扩展无符号整数类型，扩展无符号整数类型不包含在第 3.10/10 节中。现在呢？

Answer 1

好吧，让我们变得真正迂腐。在阅读了this、this 和this 之后，我非常有信心了解这两个标准背后的意图。

因此，从std::uint8_t* 到char* 执行reinterpret_cast 然后解除对结果指针的引用是安全 和可移植 并且是[basic.lval] 明确允许的。

但是，从 char* 到 std::uint8_t* 执行 reinterpret_cast 然后解除对结果指针的引用违反了严格的别名规则并且是未定义的行为如果@ 987654332@ 被实现为扩展的无符号整数类型。

但是，有两种可能的解决方法，第一种：

static_assert(std::is_same_v<std::uint8_t, char> ||
    std::is_same_v<std::uint8_t, unsigned char>,
    "This library requires std::uint8_t to be implemented as char or unsigned char.");

有了这个断言，你的代码将不会在平台上编译，否则会导致未定义的行为。

第二：

std::memcpy(uint8buffer, charbuffer, size);

Cppreference 表示std::memcpy 将对象作为unsigned char 的数组访问，因此它是安全和便携。

重申一下，为了能够在 char* 和 std::uint8_t* 之间进行 reinterpret_cast 并以 100% 标准便携和安全使用生成的指针-符合方式，必须满足以下条件：

• CHAR_BIT == 8。
• std::uint8_t 已定义。
• std::uint8_t 实现为 char 或 unsigned char。

实际上，上述条件在 99% 的平台上都为真，并且很可能没有平台可以满足前 2 个条件为真而第 3 个条件为假的情况。

Answer 2

如果uint8_t 存在，本质上唯一的选择是它是unsigned char 的typedef（或者char，如果它恰好是未签名的）。没有什么（除了位域）可以表示比char 更少的存储空间，而唯一可以小至8 位的其他类型是bool。下一个最小的普通整数类型是short，它必须至少为 16 位。

因此，如果uint8_t 存在，那么您实际上只有两种可能性：您要么将unsigned char 转换为unsigned char，要么将signed char 转换为unsigned char。

前者是身份转换，所以显然是安全的。后者属于 §3.10/10 中为访问任何其他类型作为 char 或 unsigned char 序列而给出的“特殊分配”，因此它也给出了定义的行为。

由于包括char 和unsigned char，因此将其作为字符序列访问的强制转换也给出了定义的行为。

编辑：就 Luc 提到的扩展整数类型而言，我不确定您如何设法应用它以在这种情况下有所作为。 C++ 引用了 C99 标准来定义 uint8_t 等，因此其余部分的引号来自 C99。

§6.2.6.1/3 指定unsigned char 应使用纯二进制表示，没有填充位。填充位仅在 6.2.6.2/1 中允许，特别排除了unsigned char。然而，该部分详细描述了纯二进制表示 - 从字面上看。因此，unsigned char 和 uint8_t（如果存在）必须在位级别以相同的方式表示。

要看到两者之间的差异，我们必须断言，某些特定位在被视为一个时会产生与另一个不同的结果——尽管事实上两者在位级别上必须具有相同的表示。

更直接地说：两者之间的结果差异要求他们以不同的方式解释位 - 尽管直接要求他们以相同的方式解释位。

即使在纯理论层面上，这似乎也难以实现。在任何接近实际水平的东西上，这显然是荒谬的。