‫پارادایم جدید امنیت حافظه در C# 16: بازطراحی مکانیسم Unsafe با الهام از Rust

• تعامل با کد native که آدرس خام و طول انتظار دارد.
• کسب آخرین ذره عملکرد در حلقه‌های تنگ با حذف بررسی مرز آرایه.
• خواندن و بازتفسیر مستقیم بایت‌ها، مثلاً هنگام پارس کردن فرمت‌های باینری.

static unsafe void Copy(byte[] source, int sourceOffset,
                        byte[] target, int targetOffset, int count)
{
    if (source == null || target == null)
        throw new ArgumentException("source or target is null");
    if (sourceOffset < 0 || targetOffset < 0 || count < 0)
        throw new ArgumentException("offset or count is negative");
    if (source.Length - sourceOffset < count ||
        target.Length - targetOffset < count)
        throw new ArgumentException("not enough room to copy");

    // پین کردن آرایه‌ها تا GC آن‌ها را جابه‌جا نکند
    fixed (byte* pSource = source, pTarget = target)
    {
        for (int i = 0; i < count; i++)
            pTarget[targetOffset + i] = pSource[sourceOffset + i];
    }
}

• مستقل از محل حافظه: می‌تواند به آرایه مدیریت‌شده، بلوک stackalloc، فیلد داخل شیء، کاراکتر داخل رشته یا حافظه native اشاره کند.
• بر پایه managed pointers (byrefs در CLR) کار می‌کند که GC آن‌ها را هنگام جابه‌جایی اشیاء به‌روزرسانی می‌کند. بنابراین نیازی به fixed نیست.
• به دلیل محدودیت stack، نمی‌تواند در heap ذخیره شود (برای جلوگیری از dangling reference). کامپایلر این را با ref struct تضمین می‌کند.

var data = new byte[10];
Span<byte> bytes = data;  // تبدیل ضمنی

Span<byte> middle = bytes.Slice(start: 2, length: 4);
middle[0] = 42;  // مستقیماً در data[2] نوشته می‌شود
// middle[4] = 1; // IndexOutOfRangeException

Span<int> numbers = stackalloc int[3];

const int StackLimit = 256;
Span<byte> buffer = length <= StackLimit
    ? stackalloc byte[length]
    : new byte[length];

• امنیت: باگ‌های حافظه (buffer overrun، dangling pointer، type confusion) منبع اصلی آسیب‌پذیری‌های امنیتی هستند. آژانس‌هایی مانند CISA، NSA و FBI بر لزوم حرکت به سمت زبان‌های memory-safe تأکید دارند. unsafe تنها جایی است که کامپایلر مسئولیت را به توسعه‌دهنده واگذار می‌کند. هدف جدید: شفاف، محدود و قابل بررسی کردن این مرز.
• AI-assisted coding: با سرعت تولید کد توسط ابزارهای هوش مصنوعی، نیاز به قراردادهای صریح بیشتر احساس می‌شود.
• سازگاری با اکوسیستم: runtime libraries مایکروسافت نیز بر اساس این مدل بازنویسی می‌شوند.

• فراخوانی یک عضو unsafe خارج از زمینه unsafe حالا خطای کامپایل تولید می‌کند (نه فقط warning).

void Caller()
{
    M();  // خطا: فراخوانی M() خارج از unsafe context
}

unsafe void M() { }

• دیگر نمی‌توان کل نوع (class/struct) را unsafe کرد. unsafe فقط روی متدها، پراپرتی‌ها، فیلدها و local functions اعمال می‌شود.
• این تغییر granularity را افزایش می‌دهد و کد را دقیق‌تر می‌کند.

• صرفاً تعریف یا پاس دادن نوع pointer (مثل byte*) دیگر unsafe محسوب نمی‌شود.
• فقط dereference (خواندن/نوشتن از طریق اشاره‌گر، مثل data[i]) نیاز به بلوک unsafe دارد.

• تمام عملیات unsafe باید داخل بلوک unsafe { ... } قرار گیرند. این کار scoping را محدود و بررسی کد را آسان می‌کند.

• هر عضو unsafe باید بخش /// داشته باشد که تعهدات caller را به وضوح توصیف کند.
• داخل پیاده‌سازی، کامنت‌های // SAFETY: برای توضیح منطق ایمنی استفاده می‌شود.
• analyzerها عدم وجود این مستندات را flag می‌کنند.

• برای اعلام صریح اینکه یک extern method یا LibraryImport ایمن است و unsafety را propagate نمی‌کند.

/// <safety>
/// Callers must pass a non-null pointer to at least <paramref name="length"/>
/// readable bytes. The memory must stay alive for the duration of the call.
/// </safety>
static unsafe int SumBytes(byte* data, int length)
{
    // SAFETY: length توسط wrapper عمومی اعتبارسنجی شده و قرارداد caller
    // تضمین می‌کند data حداقل به این اندازه بایت معتبر اشاره دارد.
    int total = 0;
    unsafe
    {
        for (int i = 0; i < length; i++)
            total += data[i];
    }
    return total;
}

• توسعه‌دهنده باید صراحتاً تضمین دهد که کد ایمن است.
• هر تابع unsafe باید در مستندات (/// # Safety) دقیقاً بنویسد که caller چه تعهداتی باید رعایت کند (مثلاً «این اشاره‌گر نباید null باشد»، «حافظه باید حداقل X بایت معتبر باشد»، «طول عمر حافظه باید تا پایان فراخوانی تضمین شود» و غیره).
• کامنت‌های // SAFETY: داخل پیاده‌سازی برای توضیح منطق ایمنی استفاده می‌شود.
• unsafe به صورت صریح propagate می‌شود (یعنی فراخوانی یک تابع unsafe، caller را هم unsafe می‌کند مگر اینکه boundary ایمن بسازید).

• unsafe به عنوان قرارداد صریح: دیگر فقط یک بلاک نحوی نیست، بلکه یک قرارداد caller-facing است. فراخوانی عضو unsafe خارج از زمینه unsafe، خطای کامپایل می‌دهد.
• مستندات اجباری : دقیقاً مشابه /// # Safety در Rust. هر متد unsafe باید توضیح دهد caller چه تضمین‌هایی باید بدهد.
• کامنت‌های // SAFETY: داخل کد برای توضیح منطق.
• محدود کردن دامنه: unsafe فقط در سطح member (متد، پراپرتی، فیلد) اعمال می‌شود، نه کل کلاس.
• تفاوت بین نوع pointer و dereference: فقط عملیات خطرناک (dereference) نیاز به بلاک unsafe دارد.
• propagation کنترل‌شده: unsafe فقط وقتی propagate می‌شود که صراحتاً روی signature عضو گذاشته شود.