std::ptr::addr_of! makrosu, doğrudan referans oluşturma ara adımını atlayarak alanlara ham işaretçiler oluşturmayı sağlayarak güvensiz Rust'ta kritik bir rol oynamaktadır. #[repr(packed)] yapıları ile çalışırken, alanlar hizalanmamış bellek ofsetlerinde bulunabilir; bu da referans türlerinin sahip olduğu hizalama gereksinimlerini ihlal eder. Böyle hizalanmamış verilere & operatörü ile referans oluşturmayı denemek, referansın daha sonra kullanılıp kullanılmamasına bakılmaksızın hemen tanımsız davranış oluşturur. addr_of! makrosu, alanın adresinden doğrudan bir ham işaretçi oluşturarak bu durumu ortadan kaldırır ve referanslar tarafından uygulanan hizalama ve geçerlilik invariantsını atlar. Bu ayrım, paket verilerinin yaygın olduğu sağlam FFI etkileşimleri ve düşük seviyeli bellek manipülasyonu için kritik öneme sahiptir.
Bir miras ikili protokolü için yüksek performanslı bir ayrıştırıcı geliştirirken, mühendislik ekibi, u32 alanının dış donanım kayıt haritasıyla eşleşmek için kasıtlı olarak 1 byte ofsetle yerleştirildiği bir #[repr(packed)] yapısı ile karşılaştı. Başlangıç uygulaması bu alanı &packet.status_register kullanarak bir doğrulama fonksiyonuna geçirmeye çalıştı, bu da hizalanmamış bir referans oluşturmasına ve hemen tanımsız davranışa yol açtığını bilmeden.
İlk önerilen çözüm, packed niteliğini kaldırmak ve hizalamayı zorlamak için manuel olarak padding baytları eklemek oldu. Bu yaklaşım, doğal referans oluşturma olanağı sunduğu için güvenliği garanti ediyordu, ancak donanım spesifikasyonuyla ikili uyumluluğu bozdu ve bu yapıların büyük dizilerini aktarırken bellek bant genişliğini israf etti.
İkinci yaklaşım, unsafe { &*(base_ptr.add(1) as *const u32) } ile işaretçi aritmetiği kullanarak alan adresini manuel olarak hesaplamayı önerdi. Bu doğrudan alan erişim sözdizimi kullanımını önlese de, yine de &* dereferans operatörü aracılığıyla bir referans oluşturuyordu ki bu da sonuçtaki işaretçi düzgün hizalanmamışsa tanımsız davranış anlamına gelir ve orijinal naif ödünç alma üzerinde herhangi bir güvenlik iyileştirmesi sunmazdı; bu durum gelecekteki bakımcıları yanıltabilirdi.
Ekip nihayet üçüncü çözümü seçti; std::ptr::addr_of! kullanarak hizalanmamış alana referans oluşturmadan ham bir işaretçi türetti. Daha sonra bu işaretçi, düzgün hizalanmış yerel bir değişkene güvenli bir şekilde kopyalamak için std::ptr::read_unaligned'e geçirildi. Bu strateji, gerekli bellek düzenini korurken Rust'ın bellek modeline sıkı bir şekilde uyum sağladı ve Miri ile titiz testlerden geçti ve ARM ve x86_64 dahil olmak üzere birden fazla hedef mimaride düzgün çalıştı.
Neden hizalanmamış verilere bir referans oluşturmak tanımsız bir davranış oluşturur, referans hemen bir ham işaretçiye dönüştürülse bile?
Rust'ta, bir referans oluşturma eylemi—örneğin &packed.field—sadece bir işaretçi hesaplaması değil, hedef belleğin o referans türünün tüm invariantslarının, hizalama ve okuma geçerliliği dahil, karşılandığına dair derleyiciye bir iddiadır. LLVM arka ucu ve Rust'ın optimizasyonu bu invariantsların hemen referans oluşturulduğu anda geçerli olduğunu varsayıyor, bu da yükleme-depolama sıralamasında agresif optimizasyonlara veya spekülatif yüklemelere olanak tanır. Referans anında hemen *const T'ye dönüştürülse bile, optimizasyon, hizalanmış erişim varsayımına dayanan talimatlar çıkarmış olabilir veya referans değerini LLVM meta verilerinde dereferenceable olarak işaretlemiş olabilir; bu da katı hizalama gereksinimleri olan mimarilerde yanlış derlemeye yol açar. Bu nedenle, tanımsız davranış referans oluşturma anında meydana gelir, dereferans sürecinde değil ve bu da hizalanmamış bir referansın varlığının programın doğruluğu açısından toksik hale gelmesine neden olur.
addr_of! kullanmanın, mevcut bir referansa as *const _ kullanmaktan farkı nedir ve neden bu makro gereklidir?
&packed.field as *const T yazıldığında, Rust derleyicisi önce bir referans oluşturur (hizalama kontrolleri ve olası UB'yi tetikler) ve ardından o geçerli referansı bir ham işaretçiye dönüştürür. Aksine, std::ptr::addr_of! doğrudan yer ifadesi (alan) üzerinde çalışır ve asla bir referans ara öğesi oluşturmadan ham işaretçi üretir. Bu kritik öneme sahiptir çünkü derleyici addr_of! içindekini, referans geçerlilik kontrollerini atlamaya yönelik özel bir yapıdır, oysa as anahtarı, kaynak değerin (referansın) geçerli olmasını gerektiren bir değer-değer dönüşümünü gerçekleştirir. Makro kullanmak, işaretçi türetilmesinin kendisinin hizalama ihlallerinden kaynaklı tanımsız davranışa neden olamayacağını garanti eder ve potansiyel olarak hizalanmamış verilerin adreslerini elde etmenin tek sağlam yolunu sağlar.
UnsafeCell içeren bir yapının alanlarına işaretçiler elde etmek için addr_of_mut! kullanırken hangi ek değerlendirmeler geçerlidir?
Bir #[repr(packed)] yapısı UnsafeCell<T> içerdiğinde, iç kısma bir değiştirilebilir işaretçi elde etmek, Rust'ın paylaşım kurallarını dikkatli bir şekilde ele almayı gerektirir. UnsafeCell, içsel değiştirilebilirlik sağlar, ancak hizalanmamış bir UnsafeCell alanına bir değiştirilebilir referans (&mut) oluşturmak, hâlâ hizalama gereksinimlerini ihlal eder ve tanımsız davranıştır. Adaylar sıklıkla UnsafeCell'in işaretçiyi hizalama kurallarından muaf tuttuğunu varsayıyor, ancak bu yalnızca münhasır referans paylaşımı garantisinden (noalias) muaf tutar, hizalamadan muaf değildir. addr_of_mut! kullanmak, nihayetinde dereferanslandığında veya UnsafeCell::raw_get'e geçirildiğinde temel türün hizalamasına saygı göstermesi gereken bir *mut T oluşturarak, gerçek veri erişimi için read_unaligned veya write_unaligned kullanılmasını gerektirir.