std::ptr::addr_of!マクロは、参照を作成するという中間ステップを挟まずにフィールドへの生ポインタを作成することを可能にする、安全なRustにおいて重要な役割を担っています。**#[repr(packed)]構造体を扱う際、フィールドはアライメントが整っていないメモリオフセットに存在する可能性があり、参照型に内在するアライメント要件に違反します。このようなアライメントされていないデータに対して&**演算子を使用して参照を作成しようとすると、参照がその後どのように使用されるかに関わらず、直ちに未定義動作が発生します。addr_of!マクロは、フィールドのアドレスから生ポインタを直接生成することによってこれを回避し、参照によって強制されるアライメントおよび有効性の不変条件をバイパスします。この区別は、パックデータレイアウトが一般的なFFI相互作用や低レベルのメモリ操作において非常に重要です。
レガシーバイナリープロトコルの高性能パーサーを開発しているとき、エンジニアリングチームは、u32フィールドが外部ハードウェアレジスターマップに一致させるために意図的に1バイトのオフセットに配置された**#[repr(packed)]**構造体に直面しました。初期の実装では、検証関数に渡すために&packet.status_registerを使用してこのフィールドを借りようとしましたが、これによりアライメントされていない参照が生成され、即座に未定義動作が発生することになりました。
考慮された最初の解決策は、packed属性を削除し、手動でパディングバイトを挿入してアライメントを強制することでした。このアプローチは、自然な参照作成を可能にすることで安全性を保証しましたが、ハードウェア仕様とのバイナリ互換性を破壊し、この構造体の大規模な配列を転送する際にメモリ帯域幅を無駄にしました。
提案された二番目のアプローチは、unsafe { &*(base_ptr.add(1) as *const u32) }を使用して手動でフィールドアドレスを計算することでした。この方法は、直接フィールドアクセスの構文を回避しましたが、依然として&*逆参照演算子を通じて参照を生成し、結果のポインタが適切にアライメントされていない場合に未定義動作が発生するため、安全性の向上には繋がらず、将来のメンテナを誤解させる可能性がありました。
チームは最終的に、std::ptr::addr_of!を使用して、参照を中間に作成することなくアライメントされていないフィールドへの生ポインタを導出する第3の解決策を選択しました。このポインタは、その後、std::ptr::read_unalignedに渡され、安全に値を適切にアライメントされたローカル変数にコピーしました。この戦略は必要なメモリレイアウトを保持しながらRustのメモリモデルを厳守し、厳格なテストに合格したコードを生み出し、ARMやx86_64を含む複数のターゲットアーキテクチャで正しく機能しました。
アライメントされていないデータへの参照を作成することが、どのようにして未定義動作に繋がるのか、たとえ参照が即座に生ポインタにキャストされても？
Rustにおいて、参照を作成する行為—例えば&packed.field—は単なるポインタ計算ではなく、ターゲットメモリが全ての不変条件を満たすことをコンパイラに対して主張することです。これには、読み込みに対するアライメントおよび有効性が含まれます。LLVMバックエンドとRustの最適化器は、これらの不変条件が参照作成直後に成立することを前提とし、読み込み-書き込みの再配置や投機的読み込みといった攻撃的な最適化を可能にしています。参照が瞬時に*const Tにキャストされても、最適化器は整合したアクセスを前提とした命令を emit している可能性があり、あるいは参照値をLLVMメタデータ内でdereferenceableとしてマーキングしている可能性があります。そのため、未定義動作は参照作成の瞬間に発生し、逆参照する時点ではありません。したがって、アライメントされていない参照の存在自体はプログラムの正確性にとって有害です。
addr_of!がすでに存在する参照に対しas *const _を使用することとどう異なり、なぜマクロが必要なのでしょうか？
&packed.field as *const Tと書く場合、Rustコンパイラは、まず参照を作成し（アライメントチェックと潜在的なUBを引き起こす）、その後にその有効な参照を生ポインタに変換します。対照的に、**std::ptr::addr_of!**は場所表現（フィールド）に直接作用し、決して中間の参照を構築することなく生ポインタを生成します。これは重要です。なぜなら、コンパイラはaddr_of!の内部を参照の有効性チェックをスキップする特別な構造として扱うからです。一方、asキーワードは失敗しないことが必要な値から値への変換を行うため、ソース値（参照）が有効である必要があります。このマクロを使用することで、ポインタ導出自体がアライメント違反に起因する未定義動作を引き起こすことがないことが保証され、潜在的にアライメントされていないデータのアドレスを取得するための唯一の正当な方法を提供します。
UnsafeCellを含む構造体内のフィールドへのポインタを取得するためにaddr_of_mut!を使用する際に適用される追加の考慮事項は何ですか？
#[repr(packed)]構造体にUnsafeCell<T>が含まれている場合、その内部への可変ポインタを取得するためには、Rustのエイリアシングルールを慎重に扱う必要があります。UnsafeCellは内部可変性を提供しますが、アライメントされていないUnsafeCellフィールドへの可変参照（&mut）を作成することは、アライメント要件に違反し、未定義動作となります。候補者はしばしば、UnsafeCellがポインタをアライメントルールから免除するかのように考えますが、これはあくまで排他的な参照エイリアシング保証（noalias）からの免除であり、アライメントからは免除されません。addr_of_mut!を使用すると、最終的に逆参照またはUnsafeCell::raw_getに渡されたときに、基本となる型のアライメントを尊重しなければならない*mut Tが得られます。これにより、実際のデータアクセスのためにはread_unalignedやwrite_unalignedを使用する必要があります。