نگاه فنی‌تر به Memory Safety جدید در C#

تغییر اصلی اینه که در C# 16، مفهوم unsafe دقیق‌تر می‌شه. قبلاً وقتی روی یک متد unsafe می‌ذاشتیم، یعنی داخلش اجازه داریم با pointer و عملیات سطح پایین کار کنیم. اما مدل جدید بین دو چیز فرق می‌ذاره: APIای که از caller انتظار رعایت شرط ایمنی دارد و بخشی از کد که واقعاً عملیات خطرناک انجام می‌دهد.
مثلاً اگر متدی از caller می‌خواهد pointer معتبر بدهد، خود signature می‌تواند unsafe باشد. اما داخل بدنه، جایی که pointer واقعاً dereference می‌شود، باید با unsafe { } مشخص شود:

public static unsafe byte Read(byte* ptr)
{
    unsafe
    {
        return *ptr;
    }
}

اینجا unsafe بیرونی یعنی caller مسئول است pointer معتبر بدهد؛ ولی unsafe داخلی دقیقاً محل دسترسی خطرناک به حافظه را نشان می‌دهد.
چرا این مهم است؟
چون خطر اصلی صرفاً وجود pointer نیست؛ خطر اصلی جایی است که از آن pointer برای خواندن یا نوشتن حافظه استفاده می‌کنیم. مدل جدید کمک می‌کند این نقاط پنهان نمانند، مخصوصاً وقتی با IntPtr، Marshal، NativeMemory یا interop کار می‌کنیم.
همچنین unsafe APIها باید بهتر مستند شوند؛ مثلاً با بخش‌هایی مثل:

/// <safety>
/// Caller must ensure ptr points to valid readable memory.
/// </safety>

این باعث می‌شود در code review دقیق‌تر بفهمیم چه چیزی بر عهده‌ی caller است و چه چیزی داخل متد تضمین شده.

@codehalics | کدهالیک