Rust’a geçtim ama borrow checker sürekli kafamı karıştırıyor, gerçekten bellek patlamasını önleyebiliyor mu?

[Erdem Yıldırım]

Selam arkadaşlar, yıllardır C/C++ ile sistem programlaması yapıyorum son 2-3 aydır da Rust’a geçmeye çalışıyorum. İtirafım şu ki başlarda borrow checker inanılmaz sinir bozucu geldi, ‘neden sadece kodu derlememe izin vermiyorsunuz’ diye bağırdığım oldu açıkçası. 😅

Ama son zamanlarda biraz derinleşince enteresan bir şey fark ettim: C’de yıllardır başımı ağrıtan use-after-free, double-free, buffer overflow hataları burada neredeyse hiç karşıma çıkmıyor. Bunu sadece ‘derleyici kısıtlıyor’ diye geçiştirmek istemiyorum, arkasındaki mantığı gerçekten anlamak istiyorum.

RAII ile borrow checker arasındaki ilişki ne? ‘Memory safe’ demek gerçekten Undefined Behavior’ın tamamını mı yok ediyor yoksa FFI kullanınca yine her şey düşüyor mu? Bu konularda tecrübeniz var mı, nasıl öğrendiniz?

"Kusursuzluk ulaşılan bir son nokta değil; her gün daha iyisini arayan bitimsiz bir disiplindir."

[Cihan E.]

Reis selamlar, iyi ki sordun çünkü bu işin temelini anlamadan Rust yazmaya çalışmak gerçekten acı veriyor. Ben de senin yerindeydim, ilk başta ‘ne kadarını kısıyorsunuz lan’ dedim, sonra bir gün borrow checker’ın aslında bir hata ayıklayıcı değil de bir koruyucu olduğunu anlamaya başlayınca iş değişti.

Konuyu toparlayayım: Rust’ın ‘memory safe’ demesinin sebebi, bellek yönetimini derleme zamanında (compile-time) halletmeye çalışması. C/C++’ta bunları runtime’da görürsün, genelde crash olarak. Rust’ta ise borrow checker dediğin şey aslında ‘lifetime’ (ömür) analizinden ibaret. Bir referans alıyorsun ama o referansın işaret ettiği veri daha önce drop edilmişse, derleyici bunu derleme anında yakalar ve ‘this reference may be invalidated’ der. Yani use-after-free’in önüne geçmek için runtime’da bir şey yapmaz, senin kodunu o hatayı yapamayacak şekilde yazmaya zorlar.

RAII ile bağlantısı şu: Rust’ta RAII’nin karşılığı ‘Drop’ trait’i ve ownership (sahiplik) kuralı. Bir nesneye tek bir owner vardır, o scope’tan çıkınca otomatik olarak bellekten silinir. İki yerde aynı veriye erişim olamaz (mutable olmayan çoklu okuma ya da tek bir yazma). İşte borrow checker bunları zorlayan mekanizma. ‘Borç almak’ diye Türkçeye çevrilmesi aslında güzel bir benzetme çünkü bir veriye borç alıyorsun ama aynı zamanda başka birinin de aynı veriye erişmesini engellersin, bunu geri teslim edersin (drop). Döngüsel referans kurarsan leak olursa, onu da Rc/Arc ile çözersin ama genelde tasarım hatasıdır, ‘şu anlama’ demektir.

İkinci soruna gelirsem, FFI kısmı çok önemli ve çoğu insan burada takılıyor: Rust’ın memory safety garantisi SADECE Rust kodu yazdığın sürece geçerli. extern crate, C kütüphanelerine FFI ile bağlandığın an o garantiden çıkıyorsun. Yani FFI bloğunda UB yapabilirsin, Rust bunu göremez çünkü o kod Rust’ın denetimi dışında. Pratik çözüm ne? FFI’ye giren-dışaran her veriyi mümkün olduğunca azalt, raw pointer’ları mümkün olduğunca kısa tut, mümkünse unsafe bloklarını minimize et ve mümkünse unsafe kodu safe bir wrapper’ın içine hapsederek dışarıya ‘güvenli’ bir API sun. Unsafe demek ‘ben buraya unsafe kod yazdım, doğru çalıştığından sorumluyum’ demek, ‘hatasız’ demek değil. Bu ayrımı anlamadan Rust yazırsan sürekli ‘ama C’de de unsafe kullanıyordum’ tuzağına düşersin.

UB konusundaki son sözüm: Rust’ın kendisi ‘Well-Defined Behavior’ (WDB) tarafına kaymaya çalışıyor, yani eskiden ‘undefined’ sayılan bazı şeyler artık tanımlı davranışa çekiliyor. Ama ‘memory safe’ = ‘hatasız kod’ demek değil, ‘memory ile ilgili hataları runtime’da değil derleme zamanında yakalar’ demek. Unutma, FFI’den sonra o kapı kapanıyor.

İlk baştaki siniri çok iyi anıyorum, o sinir aslında senin öğrenme eğrisinin işaretçi. Sabret, 2-3 ay sonra ‘acaba neden bu kadar katıydı’ diyeceksin. Kolay gelsin!

[Yazar]

Yazılar