#[repr(packed)] niteliği, bellek düzeninin dış spesifikasyonlarla—örneğin donanım kayıtları veya ağ protokolleri—eşleşmesi gereken sistem programlama gereksinimlerinden kaynaklanmaktadır; bu, alanlar arasındaki doldurma baytlarını ortadan kaldırarak sağlanır. Rust normalde referansların, işaretçinin gereksinimlerine göre hizalanmasını garanti etse de, paket yapıları alanları hizalama dikkate alınmaksızın ardışık bayt ofsetlerine zorlar, bu da u32 verisini dört ile bölünemeyen bir adreste yerleştirebilir. Böyle hizalanmamış bir alana referans (& veya &mut) oluşturmayı denemek, derleyici ve LLVM'nin optimizasyonlar için hizalanmış adresler varsaydığı için hemen belirsiz davranış oluşturur. Verilere güvenle erişmek için, tamamen ara referanslar oluşturmaktan kaçınılmalı, bunun yerine doğrudan ham göstericiler elde etmek için addr_of! ve addr_of_mut! makroları kullanılmalı, ardından hizalama varsayımları olmadan veri kopyalamak için ptr::read_unaligned veya ptr::write_unaligned kullanılmalıdır.
use std::ptr::{addr_of, read_unaligned}; #[repr(packed)] struct Paket { bayraklar: u8, zaman damgası: u64, // Muhtemelen 1 ofsetinde, hizalanmamış } fn zaman_damgasi_al(p: &Paket) -> u64 { // UB: &p.zaman_damgası hizalanmamış bir referans oluşturur let ham_ptr = addr_of!(p.zaman_damgası); unsafe { read_unaligned(ham_ptr) } }
Bir ikili finansal protokol (FIX) için sıfır kopyalı bir ayrıştırıcı geliştirirken, ekip, hizalama olmadan hemen ardından u8 mesaj türünü takip eden bir u64 zaman damgası olan bir yapı gerektiriyordu. İlk uygulama, doğrudan alan erişimi ile #[repr(packed)] kullanarak, hizalanmamış erişimlerin çekirdeğe tuzak kurduğu ARM mimarilerinde ara sıra segmentasyon hatalarına neden oldu.
Birçok çözüm değerlendirildi. Öncelikle, oluşturma ve OR işlemleri kullanarak byte byte manuel yeniden yapılandırma: bu, hizalama sorunlarını ortadan kaldırdı ancak paket başına önemli bir CPU yükü getirdi ve denetimi komplike eden hata yapmaya eğilimli bit-twiddling mantığı getirdi. İkinci olarak, hizalamayı zorlamak için açık doldurma alanları ile #[repr(C)] kullanmak: bu güvenliği korudu ama sonraki alanların byte ofsetlerini değiştirerek protokol uyumluluğunu bozdu ve verileri iletimden önce yeniden düzenlemek için pahalı bellek kopyaları gerektirdi. Üçüncü olarak, #[repr(packed)] kullanarak ancak hizalanmamış okumalarla ham göstericiler aracılığıyla alanlara erişmek: bu, belirsiz davranıştan kaçınarak tam bellek düzenini korudu.
Ekip, addr_of!(self.zaman_damgası) ardından ptr::read_unaligned kullanan bir getter yöntemi uygulamayı seçti. Bu, ARM ve x86_64'deki çöküşleri ortadan kaldırdı ve sıfır kopyalı mimariyi korurken gecikmeyi byte-yeniden yapılandırma yaklaşımına kıyasla %40 oranında azalttı.
Hizalanmamış bir alana referans oluşturmanın, hizalanmamış erişimi destekleyen mimarilerde bile neden belirsiz davranış oluşturduğunu anlamak?
x86_64 işlemcileri, donanımda hizalanmamış yüklemeleri tolere etse de, Rust'ın belirsiz davranış kuralları, agresif optimizasyonlara olanak tanımak için donanım yeteneklerinden daha katıdır. Derleyici &u32 gördüğünde, adresin dört bayt hizalı olduğunu varsayar ve buna göre SIMD talimatları yayarak, sonraki hizalama kontrollerinin optimize edilmesine ya da bellek işlemlerinin yeniden sıralanmasına izin verir. Bu varsayıma karşı gelmek—affedici donanımda bile—derleyicinin kodu yanlış derlemesine olanak tanır ve gelecekteki derleyici sürümlerinde veya farklı mimarilerde çöküşlere veya sessiz veri bozulmasına yol açabilir.
addr_of! makrosu, paket yapı alanlarına uygulandığında & operatöründen semantik olarak nasıl farklıdır?
& operatörü, konsept olarak önce bir referans oluşturur, ardından bir ham göstericiye atanırsa onu ham bir göstericiye dönüştürür; böylece hemen hizalama geçerlilik kontrolünü tetikler. Buna karşın, addr_of!, ara bir referans oluşturmadan doğrudan adresi hesaplayan yerleşik bir makrodur; böylece hizalama gereksinimini tamamen atlar. Bu ayrım kritiktir çünkü addr_of! hizalanmamış olabilecek bir *const T döndürürken, &alan eğer alan hizalanmamışsa UB olur, hemen bir göstericiye dönüştürülse bile.
Hizalanmamış alanlar içeren bir paket yapı için Drop uygulamanın neden sorunlu olduğunu ve özel bir yok etmenin nasıl güvenli bir şekilde uygulanabileceğini belirtin.
Drop::drop metodu &mut self alır, bu hizalıdır (yapı genel hizalamayı korur), ancak bireysel alanları boşaltmak, bunların yok edicilerini &mut Alan ile çağırmayı gerektirir. Eğer bir alan, yapının başlangıcından daha yüksek bir hizalamaya sahipse ve bu nedenle hizalanmamışsa, Drop'ı çağırmak için &mut Alan oluşturmak belirsiz davranıştır. Böyle yapıları güvenli bir şekilde boşaltmak için, hizalanmamış alanları ManuallyDrop içinde sarmak gerekir; ardından özel Drop uygulamasında, addr_of_mut! ile elde edilen ham göstericiler üzerinde ptr::read_unaligned veya ptr::drop_in_place kullanarak yok edicinin hizalanmamış alana asla hizalı bir referans oluşturmadan çalışmasını sağlamak lazım.