Rust’ta C variadic kullanımı ne zaman doğru seçimdir?

Rust’ta C variadic, yalnızca FFI tarafında gerçekten gerekiyorsa anlamlıdır; normal Rust fonksiyonunda aynı esnekliği beklemek doğru değildir. En güvenli yaklaşım, variadic ihtiyacını önce daraltmak, sonra ABI ve hedef platform desteğini kontrol etmektir.

Kısa özet: Rust’ta variadic çağrı ancak bazı extern ABI’lerde mümkündür; çoğu durumda daha güvenli ve daha taşınabilir çözüm slice, dizi ya da makro tabanlı bir arayüzdür.

Rust’ta variadic ihtiyacı nasıl okunmalı?​

FFI kullanan bir projede ilk soru şu olmalı: gerçekten C tarafındaki imzayı mı korumanız gerekiyor, yoksa Rust içinde daha sıkı tipli bir arayüz kurmak mı daha doğru? Rust belgeleri, normal Rust fonksiyonlarının variadic olmadığını; variadic parametrelerin ise yalnızca belirli dış ABI’lerle ilişkilendirildiğini açıkça belirtir. Bu yüzden konu, yalnızca sözdizimi değil, doğrudan ABI uyumluluğu problemidir.

Ne zaman dış API’yi aynen korumak gerekir?​

C kitaplığına doğrudan bağlanıyorsanız, çağıran tarafın beklediği işaretçi türü ve çağrı kuralı çoğu zaman değiştirilemez. Bu durumda variadic, Rust’ın “daha iyi” bir alternatifi olduğu için değil, karşı tarafın sözleşmesi öyle olduğu için gündeme gelir. Rust Reference’a göre variadic parametreler dış bloklarda yalnızca belirli ABI dizgileriyle kullanılabilir; ayrıca güvenli kabul edilip edilmeyeceği ve hedef uyumu da önemlidir. Bu, tasarım kararını “hangi dil daha rahat” sorusundan “hangi sözleşme bozulmadan korunabilir” sorusuna taşır.

Hangi ABI’lerde sınır var?​

Belgeler, variadic desteğinin her ABI’de olmadığını söyler. Rust Reference ve std belgeleri, extern fonksiyon bildirilerinde yalnızca C/C-benzeri ABI’lerin variadic olabildiğini, normal Rust ABI’sinin bunu desteklemediğini belirtir. Ayrıca platforma göre çağrı kuralı ayrıntıları değişebilir; örneğin Windows x86_32’de bazı ABI eşlemeleri variadic için farklı davranır. Bu yüzden “extern yazdım, oldu” yaklaşımı güvenilir değildir; ABI adı ile hedef platform birlikte okunmalıdır.

Güvenli kullanım sınırı neden dar?​

Variadic arayüzlerde en büyük risk, derleyicinin tüm argümanları tam tip bilgisiyle doğrulayamamasıdır. Rust tarafında da bu nedenle güvenlik alanı daralır: tür uyuşmazlığı, yanlış argüman sayısı ya da platforma özgü çağrı kuralı hatası kolayca tanımsız davranışa gidebilir. Belgelerin “variadic yalnızca belirli durumlarda” yaklaşımı, pratikte şu anlama gelir: okunabilirlik ve tür güvenliği gerekiyorsa variadic’i varsayılan çözüm yapmayın.

Rust içinde daha iyi alternatif ne olabilir?​

Eğer amaç “değişken sayıda değer almak” ise, çoğu Rust kodunda en iyi çözüm variadic değil, açık bir veri yapısıdır. Slice, dizi, iterator ya da makro tabanlı çağrı biçimi; hem çağrı yerinde daha net görünür hem de tip hatalarını derleme zamanında yakalatır. Rust ekosistemindeki variadic-benzeri yardımcı kütüphaneler bile bunu genellikle dilin yerleşik varargs mekanizmasını taklit etmekten çok, çağrı ergonomisini iyileştirmek için yapar. Bu da forumda şu ayrımı faydalı kılar: FFI sözleşmesi mi korunacak, yoksa Rust içi ergonomi mi artırılacak? Eğer ikinci durum geçerliyse, slice/makro yaklaşımı daha doğru seçimdir.

Karar verirken bakılacak kısa ölçüt​

• Karşı tarafta gerçekten C variadic imzası varsa, önce ABI uyumluluğunu doğrulayın.
• Çağrı sadece Rust içinde kalıyorsa, variadic yerine slice veya makro düşünün.
• Taşınabilirlik önemliyse, hedef platform istisnalarını ayrıca kontrol edin.
• Tip güvenliği kritikse, variadic’i son seçenek yapın.
• FFI sınırında hata maliyeti yüksekse, imzayı sadeleştiren bir sarmalayıcı yazın.

Bu konu, forumda çoğu kullanıcının doğrudan yaşayabileceği bir kararsızlığı çözer: “C API ile birebir uyum mu, yoksa Rust’a uygun güvenli arayüz mü?” Belgelerin izin verdiği alan dar olduğu için, en pratik katkı da tam burada ortaya çıkar: variadic’i yalnız zorunlu olduğu yerde kullanmak, geri kalan her yerde daha açık bir veri modeli seçmek.