历史： 在系统编程中，Rust 必须与其他需要可预见内存布局的语言（如 C）进行互操作。早期的 Rust 允许激进的编译器优化，包括任意字段重排，以最小化填充和缓存未命中的情况，而 C 则要求按声明顺序进行字段布局。这种二分法需要显式的表示属性，以确保 FFI 边界的稳定性。
问题： repr(Rust) 默认情况下允许编译器重排结构体字段、插入填充并优化特定值，这意味着二进制表示是非指定的，并可能因编译器版本而异。相对而言，repr(C) 强制执行稳定且与 C 兼容的布局，具有确定的字段偏移。当将原始字节（例如网络数据包或 C 库中的数据）转换为 repr(Rust) 结构体时，可能会违反 Rust 的内存模型，因为实际字段偏移可能与源数据不匹配，导致加载无效值或未对齐的访问。
解决方案： 显式注释旨在用于 FFI 或原始内存映射的结构体，使用 #[repr(C)] 锁定字段顺序和对齐。对于字段布局灵活性可接受的纯 Rust 代码，repr(Rust) 仍然是默认选项。在需要序列化而不涉及 FFI 时，优先考虑安全的反序列化库，而不是 mem::transmute，因为即使是 repr(C) 也不保证没有填充字节或平台特定的对齐。
#[repr(C)] struct PacketHeader { flags: u8, length: u16, // 编译器不能将其与 flags 互换 }
上下文： 在开发高性能网络入侵检测系统时，我需要直接从 mmap 的数据包环形缓冲区中解析 以太网 帧头。该系统针对 x86_64 服务器和嵌入式 ARM64 设备。
问题： 初始实现使用 repr(Rust) 结构表示 以太网 头（目标 MAC、源 MAC、以太网类型）。在尝试将原始字节切片转换为该结构以进行零拷贝解析时，在 ARM64 上偶尔发生崩溃，但在 x86_64 上没有，指示未定义行为。
解决方案 1：使用 repr(Rust) 的天真转置。 我考虑将指针简单地转换为 mem::transmute 或 std::slice::from_raw_parts，依赖于结构定义与线接口格式匹配。 优点： 零开销，无需复制。 缺点： repr(Rust) 允许编译器在 MAC 地址之前重排 以太网类型 字段以优化对齐，导致转换的结构将 MAC 字节解释为以太网类型，反之亦然。这是立即的未定义行为，并且特定于平台。
解决方案 2：显式 #[repr(C)] 注释。 添加 #[repr(C)] 强制编译器保留声明顺序，与 IEEE 802.3 标准布局完全匹配。 优点： 可预测的偏移，对 FFI 和原始内存映射安全。 缺点： 由于亚优填充的潜在性能损失（编译器无法重排字段以最小化大小），导致结构稍大，并可能导致缓存效率低下。
解决方案 3：手动字节解析（bytemuck 或手动索引）。 使用 bytemuck crate 及 Pod traits 或手动切片字节与 u16::from_be_bytes。 优点： 完全安全，无 unsafe 块，正确处理对齐。 缺点： 为字节序和逐字段复制引入的运行时开销，使代码复杂化。
选择的解决方案： 我选择了解决方案 2（#[repr(C)]）结合 #[derive(Copy, Clone)] 和显式填充字段以准确匹配 14 字节头大小。由于 NIC 驱动程序已将数据包对齐到缓存行，因此略微的缓存效率低下是可以接受的，而正确性对于安全审计至关重要。
结果： 解析器在 x86_64 和 ARM64 之间稳定。它通过 Miri 验证以进行严格的来源检查。最终，它成功与 libpcap FFI 层集成，没有崩溃或数据损坏。
向 repr(C) 结构添加显式填充字段为什么有时会改变与 C 代码的 ABI 兼容性，以及 #[repr(C, packed)] 如何改变这种风险？
向结构添加显式填充（例如，_: u16）以匹配 C 头假设 C 编译器使用相同的对齐规则。然而，Rust 和 C 在位字段打包或数组对齐方面可能存在差异。 #[repr(C, packed)] 删除所有填充，强制字段对齐到字节边界。 优点： 完全匹配打包的 C 结构。 缺点： 在 Rust 中，未对齐的字段访问变为未定义行为，除非通过 read_unaligned 进行；编译器无法优化未对齐的读取，在某些架构（如 ARM、RISC-V）上，会触发硬件异常。候选人常常忽略 packed 完全将安全负担转移到程序员。
bool 的有效性不变量如何在 repr(Rust) 和 repr(C) 之间有所不同，这如何影响将 u8 转换为 bool？
Rust 的 bool 具有严格的有效性不变量：它必须是 0x00（假）或 0x01（真）。 C 通常将任何非零值视为真。当将 C 中的 u8 转换为包含 bool 的 repr(C) 结构体时，如果 C 代码将字节设置为 0x02，则会立即引发未定义行为，即使使用 repr(C)。 repr(Rust) 与 repr(C) 的差异并没有改变 bool 的有效性不变量——Rust始终要求 0 或 1。候选人常常假设 repr(C) 从宽松 Rust 的类型不变量；它只影响布局，而不是有效性。解决方案是使用 u8 在结构中并通过 != 0 在安全代码中转换。
你能合法地将一个 &[u8] 切片转换为一个 &[ReprCStruct] 引用吗？并且除了大小外，还必须验证哪些对齐约束？
转换切片不是直接的；必须使用 align_to 或指针转换。关键的未满足约束是 对齐：u8 切片可能具有对齐 1，而 ReprCStruct 可能需要对齐 4 或 8。创建对未对齐值的引用是立即未定义行为。候选人通常检查 size_of，但忘记 align_of。解决方案是仅在验证 ptr.align_offset(std::mem::align_of::<T>()) == 0 后使用 std::slice::from_raw_parts，或复制到对齐的缓冲区。如果违反对齐，Miri 将标记为 未定义行为。