检查符号位的位置是否足以确定 IEEE-754 浮点数相对于 integer 字节序的字节序？

Question

我最近编写了一些代码，使用memcpy将float / double解包为适当宽度的无符号整数，然后使用一些位移将符号位与组合的有效数/指数分开。

注意：对于我的用例，我不需要将后两个部分彼此分开，但我确实需要它们以正确的顺序，即： {sign, (exponent, significand)} ，后一个元组打包为无符号int 足够的宽度。

我的代码运行良好，经过全面测试，没有问题； 然而，我有点惊恐地发现 IEEE-754 没有指定其二进制交换格式的字节顺序——据我了解，这意味着在浮动字节顺序的罕见情况下，我的位移可能不正确的可能性很小≠ integer 字节序。

根据此处已回答的问题，我的假设是，鉴于位移与存储中的实际字节序无关，我只需要担心我的浮点数的字节序是否与我的整数相匹配。
我在链接的答案中松散地设计了以下代码，但避免通过指针强制转换使用类型双关语，这对我来说似乎是未指定/未定义的行为领域：

#include <cstdint>
#include <cstring>

// SAME means "same as integer endianness"
enum class FloatEndian { UNKNOWN, SAME, OPPOSITE, };

FloatEndian endianness() {
    float check = -0.0f; // in IEEE-754, this should be all-zero significand and exponent with sign=1
    std::uint32_t view;
    std::memcpy(&view, &check, sizeof(check));
    switch (view) {
    case 0x80000000: // sign bit is in most significant byte
        return FloatEndian::SAME;
    case 0x00000080: // sign bit is in least significant byte
        return FloatEndian::OPPOSITE;
    default: // can't detect endianness of float
        return FloatEndian::UNKNOWN;
    }
}

如果我确保我的浮点数确实是 IEEE-754 和std::numeric_limits<T>::is_iec559 ，那么我的方法是否是一种可靠且可移植的方法来确保我在切碎它们时“以正确的方式”获得浮点数？

Answer 1

检查符号位的位置是否足以确定 IEEE-754 浮点数相对于 integer 字节序的字节序？

• 当我读到它时，鉴于 C++ 规范和 C 规范，它往往也依赖，检查符号位在技术上不足以确定float/uint32_t之间的字节序关系。 这实际上可能已经足够了，因为除了 big/little 之外的字节序很少，而且float/uint32_t字节序之间的差异也很少。

• 我会建议一个与 -0.0f 不同的常数，也许是-0.0f -0x1.ca8642p-113f ，它的模式为 0x87654321 并且将是一个更彻底的字节序测试。 很不清楚为什么 OP 想要使用一个位稀疏-0.0f来辨别 3 个可能的结果。

• 正如其他人所提到的，在 C++ 中，测试应该是编译时的，因此与仅测试符号位的简单性相比，彻底性不是运行时成本。

• 依赖is_iec559为 true 可能会不必要地限制可移植性，因为要做到这一点，需要许多非有限的合规性规则。 参考。 你的代码真的需要安静和发信号的 NAN 吗？

• 另请参阅如果is_iec559为真，这是否意味着我可以以明确定义的方式提取指数和尾数？ .

• 我希望 OP 还测试sizeof(float) == sizeof(uint32_t) else memcpy(&view, &check, sizeof(check))是错误的代码。

我的方法是一种可靠且便携的方法，可以确保在我切碎它们时“以正确的方式”获得花车吗？

• 代码不像它应该的那样健壮和可移植。

• “当我把它们切碎时”->该代码未显示，因此无法回答。 我怀疑用于支持“使用 memcpy 将浮点/双精度解包为适当宽度的无符号整数，然后使用一些位移将符号位与组合有效数/指数分开”的endianness()目标。 正是该代码值得审查。