‏امنیت حافظه واقعاً یعنی چی؟

ماجرا از این‌جا شروع می‌شه که Zig داره یه هدف کامپایل امن شبیه Fil-C رو بررسی می‌کنه و تو اون بحث ادعا شده که نتیجه‌اش «واقعاً امن» هست — برخلاف Rust که دریچهٔ فرار unsafe داره. نویسنده می‌گه نکتهٔ اصلی جای دیگه‌ایه: تعریف Fil-C از امنیت حافظه با تعریف Rust یکی نیست. Fil-C خودش رو با «بررسی‌های زمان اجرا برای جلوگیری از خطاهای قابل‌سوءاستفادهٔ حافظه» تعریف می‌کنه، نه با حذف کامل خطای حافظه.

مثالی که میاره یه ساختار C ساده‌ست: یه struct User که آرایهٔ name[8] و بلافاصله بعدش فیلد is_root رو داره، و ورودی خط فرمان با strcpy توش کپی می‌شه.

struct User {
    char name[8];
    int is_root;
};

struct User* user = malloc(sizeof(struct User));
strcpy(user->name, argv[1]);

اگه ورودی هشت کاراکتر یا بیشتر باشه، نوشتن از name رد می‌شه و به is_root می‌رسه، و برنامه I am root! چاپ می‌کنه — حتی زیر Fil-C. چون این نوشتن هنوز داخل همون allocation اتفاق افتاده، از نگاه Fil-C «قابل‌سوءاستفاده» حساب نمی‌شه و تله‌ای فعال نمی‌شه؛ فقط نوشتن بیرون از allocation تله می‌شه. نویسنده تأکید داره که این یعنی حالت پیشنهادی Zig هم واقعاً از حالت فعلی امن‌تره، پس امنیت حافظه رو می‌شه یه طیف دید.

ولی به‌جای دعوا سر تعریف دقیق، یه تعریف کاربردی پیشنهاد می‌ده: کد امن از نظر حافظه یعنی کدی که قواعد حافظه‌ش شهودی و ساده و قابل پیگیری باشه، مگه اینکه یه تابلوی بزرگ خلافش رو اعلام کنه. unsafe تو Rust، ماژول‌های ctypes و CFFI تو پایتون، JNI تو جاوا و باز کردن /proc/self/mem همه از همین تابلوها هستن. به گفتهٔ نویسنده تا وقتی تله‌های علامت‌گذاری‌نشده باقی‌ان و خود برنامه‌نویس باید حواسش بهشون باشه، گذاشتن اسم «امنیت حافظه» روی این حالت یه‌کم گمراه‌کننده‌ست.

نکات کلیدی:

• Zig داره یه هدف کامپایل امن شبیه Fil-C رو بررسی می‌کنه
• تعریف Fil-C فقط جلوی خطاهای «قابل‌سوءاستفاده» رو می‌گیره، نه هر خطای حافظه
• سرریز داخل یک allocation تله نمی‌شه و می‌تونه فیلد کناری رو خراب کنه
• امنیت حافظه یه طیفه: Fil-C از C معمولی امن‌تره، ولی امن نیست
• تعریف کاربردی: قواعد ساده و خودکار، با علامت‌گذاری صریح برای بخش ناامن