#[repr(packed)]属性は、メモリレイアウトがハードウェアレジスタやネットワークプロトコルといった外部仕様と一致する必要があるシステムプログラミングの要件から生じます。これはフィールド間のパディングバイトを排除することによって実現されます。通常、Rustは参照がそのポイント先の型の要件に対して整列されていることを保証しますが、パックされた構造体はフィールドを整列に関係なく逐次的なバイトオフセットに配置するため、u32が4で割り切れないアドレスに配置される可能性があります。このような不整合なフィールドへの参照（&または&mut）を生成しようとすると、コンパイラとLLVMは最適化（ベクタ化やアトミック操作など）を行うために整列されたアドレスを前提としているため、即座に未定義動作となります。データに安全にアクセスするには、中間参照を全く作成せず、代わりにaddr_of!とaddr_of_mut!マクロを利用して生ポインタを直接取得し、次にptr::read_unalignedまたはptr::write_unalignedを使って整列の仮定なしにデータをコピーする必要があります。
use std::ptr::{addr_of, read_unaligned}; #[repr(packed)] struct Packet { flags: u8, timestamp: u64, // オフセット1にあり、非整列 } fn get_timestamp(p: &Packet) -> u64 { // UB: &p.timestampは非整列な参照を作成します let raw_ptr = addr_of!(p.timestamp); unsafe { read_unaligned(raw_ptr) } }
バイナリ金融プロトコル（FIX）のゼロコピー解析器を開発している間、チームはワイヤ形式に正確に一致する構造体を必要としました：パディングなしで直後にu8メッセージタイプとu64タイムスタンプ。最初の実装は、直接フィールドアクセスを使用した**#[repr(packed)]を使用しており、不整列なアクセスがカーネルにトラップするARM**アーキテクチャ上で断続的なセグメンテーションフォルトを引き起こしました。
いくつかのソリューションが評価されました。まず、シフト操作とOR操作を使用したバイトごとの手動再構築：これにより整列の問題が排除されましたが、パケットごとのCPUオーバーヘッドが大幅に増加し、監査が複雑になるエラープローンなビット操作ロジックが導入されました。第二に、明示的なパディングフィールドを持つ**#[repr(C)]を使用して整列を強制する：これにより安全性は保たれましたが、次のフィールドのバイトオフセットが変更され、データを送信する前に再配置するための高コストなメモリコピーが必要となります。第三に、#[repr(packed)]**を保持しつつ、生ポインタを介してフィールドにのみアクセスして不整列な読み取りを行う：これにより、未定義動作を避けつつ正確なメモリレイアウトが維持されました。
チームは第三のアプローチを選択し、addr_of!(self.timestamp)を使用し、その後ptr::read_unalignedを使用してタイムスタンプ値を返すゲッターメソッドを実装しました。これにより、ARMおよびx86_64でのクラッシュが排除され、ゼロコピーアーキテクチャが維持され、バイト再構築アプローチに比べてレイテンシが40％減少しました。
不整列フィールドへの参照を作成することが、非整列アクセスをサポートするアーキテクチャでも未定義動作である理由は何ですか？
x86_64プロセッサはハードウェアでの不整列ロードを許容しますが、Rustの未定義動作ルールはハードウェアの能力よりも厳格で、積極的な最適化を可能にします。コンパイラが&u32を見ると、アドレスが4バイト整列であると仮定し、SIMD命令を出力したり、その後の整列チェックを最適化したり、メモリ操作の再順序を行うことが可能です。この仮定に違反することは、耐障害性のあるハードウェアでも、コンパイラがコードを誤ってコンパイルすることを許可し、将来的なコンパイラのバージョンや異なるアーキテクチャでクラッシュや静かなデータ破損を引き起こす可能性があります。
addr_of!マクロは、パックされた構造体フィールドに適用した場合、&演算子とどのように意味的に異なりますか？
&演算子は概念的に最初に参照を作成し、それを生ポインタにキャストしますので、その際に整列の有効性チェックが即座にトリガーされます。それに対して、**addr_of!**は中間参照を作成せずにアドレスを直接計算する組み込みマクロであり、整列要件を完全にバイパスします。この区別は重要で、addr_of!は誤って整列されていない可能性がある*const Tを返すのに対し、&fieldはフィールドが不整列であればUBになります。たとえその後ポインタにキャストされてもです。
整列されていないフィールドを含むパックされた構造体に対してDropを実装することが問題となるのはなぜであり、安全にカスタム破棄を実装するにはどのようにすればよいですか？
Drop::dropメソッドは&mut selfを受け取りますが、これは整列されています（構造体自体は全体の整列を維持します）が、個々のフィールドを破棄するには&mut Fieldでそのデストラクタを呼び出さなければなりません。もしフィールドが構造体の始まりよりも高い整列を持っている場合、不整列であり&mut Fieldを作成することは未定義動作です。このような構造体を安全に破棄するためには、非コピーのフィールドをManuallyDropでラップし、その後カスタムDrop実装内でaddr_of_mut!を通じて得た生ポインタに対してptr::read_unalignedまたはptr::drop_in_placeを使用してデストラクタが実行されるようにし、常に不整列フィールドへの整列参照を作成しないようにする必要があります。