> ## Content Index > Fetch the complete content index at: https://arabroot.io/llms.txt > Use this file to discover other available public pages before exploring further. # أمان الذاكرة Memory Safety: لماذا تدفع الحكومات نحو Rust؟ - URL: https://arabroot.io/articles/امان-الذاكرة-memory-safety-لماذا-تدفع-الحكومات-نحو-rust/ - Published: 2026-10-08T14:00:00.000Z - Updated: 2026-10-09T13:01:41.000Z - Description: ماذا طلبت الحكومات فعلاً بشأن C وC++، ولماذا تسبب أخطاء الذاكرة أغلب الثغرات الخطيرة، ومتى يكون Rust هو الاختيار الصحيح. - Author: فريق عرب رووت - Tags: الأدلة التقنية, أساسيات الحاسب والبرمجة, DevOps وCI/CD, الاستضافة الذاتية تسمع كثيراً في السنتين الأخيرتين جملة مثل «وزارة الدفاع الأمريكية قررت استبدال C++ بلغة Rust»، أو «الحكومة الأمريكية منعت C وC++»، وتنتشر معها صور لوثائق رسمية وأرقام عن الثغرات، فيقلق مبرمج C++ على مستقبله، ويظن مبرمج C# أو Java أن الأمر لا يعنيه. والحقيقة أبسط من العنوان وأهم منه في الوقت نفسه، فلا يوجد قرار بمنع C++، وإنما توجد مشكلة حقيقية في فئة واحدة من الأخطاء اسمها أخطاء أمان الذاكرة Memory Safety، وتوجد سلسلة من التوصيات والأبحاث الحكومية التي تطلب من الشركات أن تخطط للخروج من هذه الفئة، وتوجد شركات كبيرة بدأت فعلاً ونشرت أرقامها. وهذا المقال من مرحلة [لغات البرمجة](https://arabroot.io/start/#stage-programming) في خارطة عرب رووت، ويكمل من حيث توقف مقال [الذاكرة للمبرمجين](https://arabroot.io/articles/%D8%A7%D9%84%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86-stack-%D9%88-heap-%D9%88%D8%A7%D9%84%D9%85%D8%A4%D8%B4%D8%B1%D8%A7%D8%AA/) الذي شرح ال Stack وال Heap والمؤشرات Pointers وجامع القمامة Garbage Collector، وذكر باختصار أن المؤشر لا يمنعك من الخروج عن حدود الذاكرة، فلن نعيد شرح ذلك هنا. وسوف نناقش في هذا المقال ما يلي: - هل منعت وزارة الدفاع الأمريكية لغة C++ فعلاً، وما الذي صدر بالضبط. - لماذا تسبب أخطاء الذاكرة نحو 70% من الثغرات في منتجات Microsoft وفي متصفح Chromium، وما هي أشهر أنواعها. - تجربة عملية: ثلاثة أخطاء في برنامج C واحد، ثم نفس الأخطاء في Rust ورسائل المترجم Compiler التي ترفضها. - الخط الزمني للتوصيات الحكومية من NSA إلى CISA والبيت الأبيض وDARPA، وما هو الملزم منها وما هو غير الملزم. - ماذا فعلت Google في Android، وما وضع Rust في نواة Linux وفي Windows. - رد مجتمع C++: فكرة ال Profiles واقتراح Safe C++ وما حدث له، والتحصين Hardening المتاح اليوم. - ماذا يعني هذا كله لك كمطور، متى تختار Rust ومتى يكفيك C++ محصن. ## هل منعت وزارة الدفاع الأمريكية لغة C++؟ لا، وبحسب ما وجدناه في المصادر الرسمية لا توجد وثيقة من وزارة الدفاع الأمريكية DoD تمنع C أو C++ أو تأمر باستبدالهما بلغة Rust، والذي صدر فعلاً من جهات تابعة للوزارة شيئان: نشرة إرشادية من وكالة الأمن القومي NSA، وهي جزء من وزارة الدفاع، وبرنامج بحثي من وكالة مشاريع الأبحاث الدفاعية المتقدمة DARPA. والفرق بين التوصية والقرار هنا كبير، فالنشرة تقول إن الوكالة «تنصح المؤسسات بأن تفكر في التحول» إلى لغة آمنة للذاكرة «عندما يكون ذلك ممكناً»، والبرنامج البحثي يحاول أن يجعل ترجمة كود C إلى Rust آلية، ولا يوجد في أي منهما منع أو موعد إلزامي. وقد يتساءل البعض: من أين جاءت فكرة المنع إذن؟ والإجابة أن الرسالة تكررت من عدة جهات حكومية في وقت قصير، وكل جهة رفعت درجة اللهجة قليلاً، حتى وصلنا إلى وثيقة من CISA ومكتب التحقيقات الفيدرالي FBI تصف تطوير منتج جديد للبنية التحتية الحساسة بلغة C أو C++ بأنه «خطير» عندما تتوفر بدائل آمنة، وتطلب من الشركات أن تنشر خارطة طريق Roadmap لأمان الذاكرة، وهذه الوثيقة نفسها تقول صراحة إنها غير ملزمة. ولذلك فالوصف الصحيح هو: ليس قراراً بمنع C++، وإنما ضغط حكومي متصاعد بالتوصيات، ومعه أرقام حقيقية من الشركات، وهذا ما سوف نفصله في قسم [ماذا طلبت الحكومات فعلاً](#government). ## لماذا أخطاء الذاكرة بالذات؟ أمان الذاكرة Memory Safety يعني أن البرنامج لا يستطيع أن يقرأ أو يكتب ذاكرة لا تخصه، ولا أن يستخدم ذاكرة بعد أن حررها، ولا أن يحرر نفس الذاكرة مرتين. واللغات التي تتولى الذاكرة عنك، مثل C# وJava وGo وPython وJavaScript، تضمن ذلك بجامع القمامة وبفحص الحدود عند كل وصول إلى مصفوفة، أما C وC++ فتعطيك المؤشر والعنوان وتثق أنك لن تخطئ، وهذه الثقة هي سبب سرعتها ومرونتها، وهي نفسها سبب المشكلة. والأرقام التي تتكرر في كل الوثائق الحكومية جاءت من الشركات نفسها، وأهمها ثلاثة: - **Microsoft:** كتب فريق الاستجابة الأمنية MSRC في يوليو 2019 في مقال [A proactive approach to more secure code](https://www.microsoft.com/en-us/msrc/blog/2019/07/a-proactive-approach-to-more-secure-code?ref=arabroot.io) أن نحو 70% من الثغرات التي تعطيها Microsoft رقم CVE كل عام ما زالت مشاكل أمان ذاكرة، وتذكر [وثيقة CISA عن خرائط الطريق](https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps?ref=arabroot.io) أن هذا الرقم مبني على ثغرات الفترة من 2006 إلى 2018. - **Chromium:** تذكر [صفحة أمان الذاكرة في مشروع Chromium](https://www.chromium.org/Home/chromium-security/memory-safety/?ref=arabroot.io) أن نحو 70% من الثغرات عالية الخطورة مشاكل أمان ذاكرة، أي أخطاء في مؤشرات C وC++، ونصفها من نوع الاستخدام بعد التحرير Use After Free، والتحليل مبني على 912 ثغرة عالية أو حرجة منذ 2015. - **الثغرات المستغلة فعلاً:** في [مراجعة Project Zero لعام 2021](https://googleprojectzero.blogspot.com/2022/04/the-more-you-know-more-you-know-you.html?ref=arabroot.io) رصد فريق Google 58 ثغرة يوم صفر Zero-day استغلت في الواقع، منها 39 أي 67% أخطاء إفساد ذاكرة Memory Corruption. ولاحظ أن الرقم 70% لا يعني أن 70% من كل الثغرات في العالم سببها الذاكرة، وإنما هو نسبة داخل منتجات مكتوبة أغلبها بلغتي C وC++، فتطبيق ويب بلغة C# لن تجد فيه هذه النسبة لأن اللغة تمنع هذه الفئة أصلاً، وثغراته الشائعة من نوع آخر مثل الحقن Injection الذي شرحناه في [البرمجة الآمنة Secure Coding](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D8%A9-secure-coding-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86/). والصورة التالية تبين الأنواع الثلاثة الأشهر، بنفس الأسماء والأرقام التي سوف تظهر في التجربة: ![ثلاث لوحات: على اليمين Buffer Overflow حيث تكتب strcpy عشرة بايتات في مصفوفة name من ثمانية بايتات فيتغير is_admin من 0 إلى 66، وفي الوسط Use After Free حيث يبقى المؤشر token يشير إلى كتلة حررت ثم أعطيت لجزء آخر فيقرأ attacker-data، وعلى اليسار Double Free حيث تحرر الكتلة buf مرتين فتظهر في قائمة الكتل الحرة مرتين ويأخذها استدعاءان مختلفان لـ malloc](https://arabroot.io/content/images/2026/10/memory-safety-rust-01-bug-types.webp) تجاوز الحدود، والاستخدام بعد التحرير، والتحرير مرتين: ثلاثة أخطاء لا يمنعها مترجم C - **تجاوز حدود الذاكرة Buffer Overflow:** كتابة أو قراءة بعد نهاية المصفوفة، فتتغير بيانات أخرى بجانبها، أو تقرأ بيانات لا تخصك كما حدث في ثغرة Heartbleed التي ذكرناها في [مقال الذاكرة](https://arabroot.io/articles/%D8%A7%D9%84%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86-stack-%D9%88-heap-%D9%88%D8%A7%D9%84%D9%85%D8%A4%D8%B4%D8%B1%D8%A7%D8%AA/#pointers). - **الاستخدام بعد التحرير Use After Free:** المؤشر يبقى يحمل العنوان بعد `free`، والمكتبة قد تعطي نفس المكان لجزء آخر من البرنامج، فيقرأ الكود القديم بيانات غيره أو يكتب فوقها، وخطورة هذا النوع أن المهاجم قد يستطيع أن يتحكم فيما يوضع في المكان المحرر. - **التحرير مرتين Double Free:** تحرير نفس الكتلة مرتين يفسد قائمة الكتل الحرة في مدير الذاكرة Allocator، فقد يعطي نفس الكتلة لطلبين مختلفين. 📌 في 11 سبتمبر 2023 أصدرت Google [تحديثاً طارئاً لمتصفح Chrome](https://chromereleases.googleblog.com/2023/09/stable-channel-update-for-desktop%5F11.html?ref=arabroot.io) فيه إصلاح أمني واحد مصنف حرجاً، وهو الثغرة CVE-2023-4863 من نوع تجاوز حدود ال Heap في مكتبة WebP، وذكرت أنها تعلم بوجود استغلال لها في الواقع، وأن من أبلغ عنها فريق الأمن في Apple ومختبر Citizen Lab، وهو المختبر الذي كشف في الأسبوع نفسه [سلسلة استغلال سماها BLASTPASS](https://citizenlab.ca/2023/09/blastpass-nso-group-iphone-zero-click-zero-day-exploit-captured-in-the-wild/?ref=arabroot.io) تخترق أجهزة iPhone بمرفقات فيها صور خبيثة تصل عبر iMessage دون أي تفاعل من الضحية. ويصف [سجل الثغرة في NVD](https://nvd.nist.gov/vuln/detail/CVE-2023-4863?ref=arabroot.io) الخطأ بأنه كتابة خارج الحدود في libwebp قبل الإصدار 1.3.2 عبر صفحة HTML مصممة لذلك، ونبهت Google في التحديث نفسه إلى أن الخطأ في مكتبة خارجية تعتمد عليها مشاريع أخرى، فاحتاج كل من يستخدمها إلى تحديث. والدرس أن خطأ حدود واحداً في مكتبة صغيرة لفك الصور، مكتوبة بلغة C، كان كافياً لاختراق هواتف عن بعد. ## التجربة: ثلاثة أخطاء في برنامج C واحد الآن سوف نكتب الأخطاء الثلاثة بأنفسنا ونرى ماذا يحدث فعلاً، وكل الأوامر في هذا المقال تعمل داخل Containers بأسماء تبدأ بـ `lab-memsafe-` وتحذف تلقائياً بعد كل أمر بسبب الخيار `--rm`، فلا تحتاج إلى تثبيت مترجم على جهازك. والجدول التالي يبين ال Images والإصدارات التي ظهرت في التجربة: | الأداة | Docker Image | الإصدار الذي ظهر في التجربة | | ------ | ----------------------- | --------------------------- | | C وC++ | gcc:16.2.0 | GCC 16.2.0 مع glibc 2.41 | | Rust | rust:1.99.0-slim-trixie | rustc 1.99.0 | قم بإنشاء مجلد فارغ وضع فيه الملف `bugs.c` التالي، وفيه دالة لكل خطأ، والبرنامج يختار الدالة من أول معامل في سطر الأوامر: ```c #include #include #include struct account { char name[8]; int is_admin; }; /* 1) buffer overflow: copies the input without checking its length */ static void overflow(const char *input) { struct account acc = { .is_admin = 0 }; strcpy(acc.name, input); printf("overflow: name=%s is_admin=%d\n", acc.name, acc.is_admin); } /* 2) use after free: keeps using a pointer after free() */ static void use_after_free(void) { char *token = malloc(16); strcpy(token, "secret-token"); free(token); char *other = malloc(16); /* the allocator may hand back the same block */ strcpy(other, "attacker-data"); printf("use-after-free: token=%s\n", token); free(other); } /* 3) double free: frees the same block twice */ static void double_free(void) { char *buf = malloc(32); free(buf); free(buf); puts("double free: still running"); } int main(int argc, char **argv) { const char *which = argc > 1 ? argv[1] : ""; if (strcmp(which, "overflow") == 0) overflow(argc > 2 ? argv[2] : "guest"); else if (strcmp(which, "uaf") == 0) use_after_free(); else if (strcmp(which, "double") == 0) double_free(); else puts("usage: bugs overflow | uaf | double"); return 0; } ``` ثم قم بترجمته وتشغيله بالحالات الأربع، مرة باسم قصير ومرة باسم أطول من ثمانية أحرف، ثم الاستخدام بعد التحرير، ثم التحرير مرتين: ```bash docker run --rm --name lab-memsafe-c -v "$PWD":/w -w /w gcc:16.2.0 sh -c 'gcc -Wall -o /tmp/bugs bugs.c && /tmp/bugs overflow guest; /tmp/bugs overflow AAAAAAAAB; /tmp/bugs uaf; /tmp/bugs double; echo "exit code: $?"' ``` والمخرج سوف يكون كما يلي: ``` bugs.c: In function 'use_after_free': bugs.c:24:5: warning: pointer 'token' used after 'free' [-Wuse-after-free=] 24 | printf("use-after-free: token=%s\n", token); | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ bugs.c:21:5: note: call to 'free' here 21 | free(token); | ^~~~~~~~~~~ bugs.c: In function 'double_free': bugs.c:32:5: warning: pointer 'buf' used after 'free' [-Wuse-after-free=] 32 | free(buf); | ^~~~~~~~~ bugs.c:31:5: note: call to 'free' here 31 | free(buf); | ^~~~~~~~~ overflow: name=guest is_admin=0 overflow: name=AAAAAAAAB is_admin=66 use-after-free: token=attacker-data free(): double free detected in tcache 2 exit code: 134 Aborted (core dumped) ``` في المخرج أعلاه لاحظ التالي: - المترجم GCC نبهنا بتحذير `-Wuse-after-free` على السطرين 24 و32، وهذا جيد، ولكنه تحذير وليس خطأ، فقد أكمل الترجمة وأنتج البرنامج، والتحذيرات في مشروع كبير تضيع بين مئات غيرها. ولاحظ أنه لم يحذرنا من تجاوز الحدود في `strcpy` لأن طول الاسم لا يعرف إلا عند التشغيل. - الاسم `AAAAAAAAB` طوله تسعة أحرف ومعه حرف النهاية `\0`، أي عشرة بايتات في مصفوفة من ثمانية، فالبايتان الزائدان كتبا فوق المتغير `is_admin` الذي يليها في ال struct، فأصبحت قيمته 66 وهي رمز الحرف `B`. والبرنامج لم ينهر ولم يطبع أي تحذير، وإنما أصبح المستخدم «مديراً» بصمت، وهذا بالضبط ما يبحث عنه المخترق. - في الاستخدام بعد التحرير طبع `token` النص `attacker-data`، أي أن مدير الذاكرة في glibc أعطى نفس الكتلة المحررة للطلب التالي، والمؤشر القديم أصبح يقرأ بيانات غيره. - التحرير مرتين هو الوحيد الذي اكتشفته glibc بنفسها، فطبعت `free(): double free detected in tcache 2` وأنهت البرنامج برمز الخروج 134، ولكن هذا فحص من المكتبة لحالة بسيطة، وليس ضماناً، والسبب أن الفحص يعمل فقط عندما تكون الكتلة ما زالت في أعلى القائمة. والآن جرب نفس البرنامج مع التحسين `-O2` الذي تستخدمه أغلب بيئات الإنتاج: ```bash docker run --rm --name lab-memsafe-c -v "$PWD":/w -w /w gcc:16.2.0 sh -c 'gcc -O2 -o /tmp/bugs bugs.c 2>/dev/null && /tmp/bugs uaf | cat -v; /tmp/bugs double; echo "exit code: $?"' ``` والمخرج سوف يكون كما يلي: ``` use-after-free: token=%M-#^B double free: still running exit code: 0 ``` لاحظ أن النتيجة تغيرت تماماً، فالمؤشر المحرر طبع بايتات عشوائية، والتحرير مرتين لم يكتشف هذه المرة وأكمل البرنامج وكأن شيئاً لم يحدث. وهذا هو معنى السلوك غير المعرف Undefined Behavior في C وC++: المعيار لا يحدد ماذا يحدث عند هذه الأخطاء، فيفترض المترجم أنها لا تحدث ويحسن الكود على هذا الأساس، ولذلك قد يمر الخطأ في الاختبارات بإعدادات معينة وينفجر في الإنتاج بإعدادات أخرى. ## نفس الأخطاء في Rust: المترجم يرفض البرنامج لغة Rust بدأت كما ذكرنا في [قصص لغات البرمجة](https://arabroot.io/articles/%D9%82%D8%B5%D8%B5-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D9%85%D9%86-%D8%B5%D9%86%D8%B9%D9%87%D8%A7/#rust) مشروعاً شخصياً لمبرمج في Mozilla، وهدفها أن تعطيك أداء C دون جامع قمامة ودون أخطاء الذاكرة، والطريقة هي قواعد الملكية Ownership التي يفحصها المترجم قبل التشغيل. والملف `bugs.rs` التالي يحاول أن يرتكب نفس الأخطاء، ومعها خطآن آخران مشهوران في C++، وهما مرجع يعيش أطول من القيمة التي يشير إليها Dangling Reference، وتعديل مصفوفة أثناء الاحتفاظ بمرجع إلى أحد عناصرها: ```rust // The same three mistakes, written in Rust. // 2) use after free: use a value after it has been freed fn use_after_free() { let token = String::from("secret-token"); drop(token); // frees the heap memory now println!("token={token}"); } // 3) double free: free the same value twice fn double_free() { let buf = vec![0u8; 32]; drop(buf); drop(buf); } // a reference that outlives the value it points to (dangling pointer) fn dangling() { let r; { let s = String::from("short-lived"); r = &s; } // s is freed here println!("r={r}"); } // changing a vector while holding a reference into it fn invalidation() { let mut prices = vec![10, 20, 30]; let first = &prices[0]; prices.push(40); // may move the whole buffer to a new place println!("first={first}"); } fn main() { use_after_free(); double_free(); dangling(); invalidation(); } ``` الآن نقوم بترجمته: ```bash docker run --rm --name lab-memsafe-rs -v "$PWD":/w -w /w rust:1.99.0-slim-trixie sh -c 'rustc --version && rustc bugs.rs -o /tmp/bugs' ``` والمخرج سوف يكون كما يلي: ``` rustc 1.99.0 (b940084d7 2026-09-28) error[E0382]: borrow of moved value: `token` --> bugs.rs:7:22 | 5 | let token = String::from("secret-token"); | ----- move occurs because `token` has type `String`, which does not implement the `Copy` trait 6 | drop(token); // frees the heap memory now | ----- value moved here 7 | println!("token={token}"); | ^^^^^ value borrowed here after move | help: consider cloning the value if the performance cost is acceptable | 6 | drop(token.clone()); // frees the heap memory now | ++++++++ error[E0382]: use of moved value: `buf` --> bugs.rs:14:10 | 12 | let buf = vec![0u8; 32]; | --- move occurs because `buf` has type `Vec`, which does not implement the `Copy` trait 13 | drop(buf); | --- value moved here 14 | drop(buf); | ^^^ value used here after move | help: consider cloning the value if the performance cost is acceptable | 13 | drop(buf.clone()); | ++++++++ error[E0597]: `s` does not live long enough --> bugs.rs:22:13 | 21 | let s = String::from("short-lived"); | - binding `s` declared here 22 | r = &s; | ^^ borrowed value does not live long enough 23 | } // s is freed here | - `s` dropped here while still borrowed 24 | println!("r={r}"); | - borrow later used here error[E0502]: cannot borrow `prices` as mutable because it is also borrowed as immutable --> bugs.rs:31:5 | 30 | let first = &prices[0]; | ------ immutable borrow occurs here 31 | prices.push(40); // may move the whole buffer to a new place | ^^^^^^^^^^^^^^^ mutable borrow occurs here 32 | println!("first={first}"); | ----- immutable borrow later used here error: aborting due to 4 previous errors Some errors have detailed explanations: E0382, E0502, E0597. For more information about an error, try `rustc --explain E0382`. ``` في المخرج أعلاه لاحظ التالي: - المترجم رفض البرنامج كاملاً بأربعة أخطاء، ولم ينتج ملفاً تنفيذياً أصلاً، فالفرق عن C ليس أن Rust تحذرك، وإنما أن هذا الكود لا يمكن أن يصل إلى السيرفر. - الخطأ `E0382` ظهر مرتين، مرة للاستخدام بعد التحرير ومرة للتحرير مرتين، والسبب واحد: `drop(token)` نقل Move ملكية القيمة إلى الدالة `drop` التي حررتها، فأصبح المتغير `token` غير صالح، وأي استخدام له بعدها خطأ ترجمة، سواء كان طباعة أو تحريراً ثانياً. ولاحظ أن اقتراح المترجم `clone()` آمن أيضاً، لأنه ينشئ نسخة مستقلة لها مالكها، فتحرر كل نسخة مرة واحدة. - الخطأ `E0597` يعني أن المرجع `r` يعيش أطول من القيمة `s`، وهذا هو المؤشر المعلق Dangling Pointer في C. - الخطأ `E0502` يمنع إضافة عنصر إلى `prices` بينما يوجد مرجع إلى عنصرها الأول، والسبب أن `push` قد يحجز مساحة أكبر وينقل كل العناصر إليها، فيصبح المرجع القديم يشير إلى ذاكرة محررة، وهو خطأ معروف في C++ مع `std::vector` باسم Iterator Invalidation. والصورة التالية تبين [قواعد الملكية](https://doc.rust-lang.org/book/ch04-01-what-is-ownership.html?ref=arabroot.io) التي أنتجت هذه الأخطاء الأربعة، وقد ذكرناها باختصار في [مقال الذاكرة](https://arabroot.io/articles/%D8%A7%D9%84%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86-stack-%D9%88-heap-%D9%88%D8%A7%D9%84%D9%85%D8%A4%D8%B4%D8%B1%D8%A7%D8%AA/#rust-ownership): ![أربع لوحات من اليمين إلى اليسار: ONE OWNER حيث المتغير a في ال stack يشير إلى النص hi في ال heap، ثم MOVE حيث let b = a ينقل الملكية ويصبح a ملغى مع الخطأ E0382، ثم BORROW حيث مرجعان للقراءة &b يشيران إلى القيمة بينما &mut b مرفوض مع الخطأ E0502، ثم DROP حيث تحرر الذاكرة عند نهاية النطاق مرة واحدة دون تحرير مزدوج](https://arabroot.io/content/images/2026/10/memory-safety-rust-03-ownership.webp) مالك واحد، والملكية تنتقل ولا تنسخ، وقراء كثيرون أو كاتب واحد، والتحرير يحدث مرة واحدة عند نهاية النطاق 1. **مالك واحد Owner:** لكل قيمة في ال Heap متغير واحد يملكها، وهو المسؤول عن تحريرها. 2. **النقل Move:** عندما تسند القيمة إلى متغير آخر أو تمررها إلى دالة تنتقل الملكية، والمتغير القديم لا يعود صالحاً، ولذلك لا يوجد مالكان يحرران نفس الذاكرة. 3. **الاستعارة Borrowing:** إذا أردت أن تستخدم القيمة دون أن تملكها فإنك تأخذ مرجعاً، إما مراجع كثيرة للقراءة `&`، أو مرجعاً واحداً للتعديل `&mut`، ولا يجتمعان في الوقت نفسه، والجزء من المترجم الذي يفحص ذلك اسمه ال Borrow Checker. 4. **التحرير Drop:** عندما يخرج المالك من النطاق Scope يحرر المترجم القيمة تلقائياً، مرة واحدة فقط. وقد يتساءل البعض: وماذا عن تجاوز الحدود؟ فالفهرس Index يأتي من المستخدم عند التشغيل، والمترجم لا يعرفه. والإجابة أن Rust تفحص حدود المصفوفة عند كل وصول، وهذا الملف `bounds.rs` ينسخ الاسم إلى مصفوفة من ثمانية بايتات كما فعلنا في C: ```rust // 1) buffer overflow: the index comes from the user at run time use std::env; fn main() { let mut name = [b'-'; 8]; let input = env::args().nth(1).unwrap_or_else(|| "guest".to_string()); for (i, byte) in input.bytes().enumerate() { name[i] = byte; // checked on every access } println!("name={}", String::from_utf8_lossy(&name)); } ``` ```bash docker run --rm --name lab-memsafe-rs -v "$PWD":/w -w /w rust:1.99.0-slim-trixie sh -c 'rustc -O bounds.rs -o /tmp/bounds && /tmp/bounds guest; /tmp/bounds AAAAAAAAB; echo "exit code: $?"' ``` والمخرج سوف يكون كما يلي: ``` name=guest--- thread 'main' (35) panicked at bounds.rs:8:9: index out of bounds: the len is 8 but the index is 8 note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace exit code: 101 ``` لاحظ أن البرنامج توقف بما تسميه Rust ال Panic عند البايت التاسع، برسالة تذكر السطر وطول المصفوفة والفهرس، ورمز الخروج 101\. والتوقف هنا ليس شيئاً جيداً للمستخدم، فالخدمة سقطت، ولكنه أفضل بكثير من نتيجة C التي أعطت المستخدم صلاحية المدير بصمت، والسبب أن السقوط خطأ تراه في السجلات Logs وتصلحه، أما الإفساد الصامت فيستغله المخترق دون أن تعرف. وفي الكود الحقيقي تستخدم الدالة `get` التي ترجع `Option` بدلاً من الفهرس المباشر، فتتعامل مع الحالة دون سقوط، وقد شرحنا `Option` في [أنماط البرمجة وأنظمة الأنواع](https://arabroot.io/articles/%D8%A7%D9%86%D9%85%D8%A7%D8%B7-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/). ويجب أن تعرف أن Rust ليست سحراً، فاللغة فيها الكلمة `unsafe` التي تسمح بعمليات لا يستطيع المترجم أن يتحقق منها، مثل التعامل مع مكتبات C أو قراءة الذاكرة دون فحص الحدود، وهذا الملف `unsafe.rs` يقرأ العنصر رقم 1000 من مصفوفة فيها ثلاثة عناصر: ```rust // unsafe switches the checks off: the compiler trusts you fn main() { let prices = vec![10, 20, 30]; let value = unsafe { *prices.get_unchecked(1000) }; println!("prices[1000]={value}"); } ``` ```bash docker run --rm --name lab-memsafe-rs -v "$PWD":/w -w /w rust:1.99.0-slim-trixie sh -c 'rustc -O unsafe.rs -o /tmp/u && /tmp/u; echo "exit code: $?"; rustc unsafe.rs -o /tmp/u-debug && /tmp/u-debug; echo "exit code: $?"' ``` والمخرج سوف يكون كما يلي: ``` exit code: 132 Illegal instruction (core dumped) thread 'main' (60) panicked at unsafe.rs:4:34: unsafe precondition(s) violated: slice::get_unchecked requires that the index is within the slice This indicates a bug in the program. This Undefined Behavior check is optional, and cannot be relied on for safety. note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace thread caused non-unwinding panic. aborting. Aborted (core dumped) exit code: 134 ``` لاحظ أن المترجم قبل الكود في الحالتين لأنك قلت له «أنا أتحمل المسؤولية»، وفي الإصدار المحسن `-O` انهار البرنامج بخطأ `Illegal instruction`، لأن المترجم افترض أن الفهرس صحيح كما وعدته، وهذا نفس السلوك غير المعرف الذي رأيناه في C. أما في إصدار التطوير Debug فقد أضافت Rust فحصاً اختيارياً أوقف البرنامج، والرسالة نفسها تقول إنه فحص لا يعتمد عليه للأمان. ولذلك فالقاعدة في مشاريع Rust: اجعل كتل `unsafe` صغيرة ومعزولة داخل دوال آمنة، وراجعها كما تراجع كود C، والسبب أن كل ضمانات اللغة تتوقف عند حدودها. ## ماذا طلبت الحكومات فعلاً؟ الآن بعد أن رأينا المشكلة بأعيننا، نعود إلى السؤال الذي بدأنا به، وهو ما الذي صدر بالضبط ومتى. والصورة التالية تبين التوصيات الحكومية فوق الخط، وما فعلته الشركات ولجنة C++ تحته: ![خط زمني من 2019 إلى 2026: فوق الخط بالأزرق NSA في نوفمبر 2022، وCISA مع NSA وFBI وأربع دول في ديسمبر 2023، وتقرير البيت الأبيض في فبراير 2024، وبرنامج DARPA TRACTOR في يوليو 2024، ووثيقة الممارسات السيئة من CISA وFBI في أكتوبر 2024، ودليل NSA وCISA في يونيو 2025، وتحت الخط بالأخضر Microsoft في 2019 وLinux 6.1 في 2022 وAndroid في نوفمبر 2025 وقمة مطوري Linux في ديسمبر 2025، وبالبنفسجي ورقة Stroustrup في ديسمبر 2022 وSafe C++ في سبتمبر 2024 وانتهاء C++26 في مارس 2026](https://arabroot.io/content/images/2026/10/memory-safety-rust-02-timeline.webp) كل ما فوق الخط توصيات وأبحاث، ولا توجد بينها وثيقة تمنع C أو C++ ### نوفمبر 2022: نشرة NSA عن أمان الذاكرة نشرت وكالة الأمن القومي الأمريكية NSA نشرة إرشادية Cybersecurity Information Sheet بعنوان [Software Memory Safety](https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI%5FSOFTWARE%5FMEMORY%5FSAFETY.PDF?ref=arabroot.io)، تذكر فيها رقم Microsoft ورقم Chrome، ثم تقول إن الوكالة تنصح المؤسسات بأن تفكر في تحول استراتيجي من اللغات التي لا توفر حماية للذاكرة أو توفر القليل منها، مثل C وC++، إلى لغة آمنة للذاكرة عندما يكون ذلك ممكناً، وتذكر أمثلة: C# وGo وJava وRuby وRust وSwift. وفي [الإصدار 1.1 في أبريل 2023](https://media.defense.gov/2023/Apr/27/2003210083/-1/-1/0/CSI%5FSOFTWARE%5FMEMORY%5FSAFETY%5FV1.1.PDF?ref=arabroot.io) أصبحت القائمة Python وJava وC# وGo وDelphi/Object Pascal وSwift وRuby وRust وAda، وأضيفت لغة Assembly إلى جانب C وC++. ولاحظ ثلاثة أشياء في هذه النشرة: الأولى أن الكلمات «تنصح» و«تفكر» و«عندما يكون ممكناً» هي لغة توصية، والثانية أن Rust واحدة من قائمة طويلة، وأغلب القائمة لغات يستخدمها قراء هذا الموقع كل يوم، والثالثة أن النشرة نفسها تقول إن اللغات الآمنة لا تعطي حماية مطلقة، وتنصح بالتحصين والفحص حتى معها. وهذه النشرة هي أقرب شيء صدر من وزارة الدفاع إلى موضوعنا، لأن NSA جزء منها، وهي على الأغلب أصل جملة «وزارة الدفاع استبدلت C++». ### ديسمبر 2023: خمس دول تطلب خارطة طريق في 6 ديسمبر 2023 نشرت وكالة الأمن السيبراني وأمن البنية التحتية CISA وثيقة [The Case for Memory Safe Roadmaps](https://www.cisa.gov/resources-tools/resources/case-memory-safe-roadmaps?ref=arabroot.io)، ووقع عليها معها NSA وFBI والجهات المختصة بالأمن السيبراني في أستراليا وكندا والمملكة المتحدة ونيوزيلندا. والوثيقة موجهة إلى إدارات الشركات قبل المبرمجين، وتطلب من كل شركة تصنع برمجيات أن تكتب وتنشر خارطة طريق لأمان الذاكرة Memory Safety Roadmap، أي خطة تقول فيها أي أجزاء منتجها سوف تنتقل إلى لغة آمنة ومتى، وما الذي سوف تفعله بالكود القديم حتى ذلك الوقت. ولاحظ أنها لا تطلب إعادة كتابة كل شيء، وإنما خطة بأولويات، تبدأ بالكود الجديد والكود المعرض للشبكة. ### فبراير 2024: تقرير البيت الأبيض في 26 فبراير 2024 نشر مكتب المدير الوطني للأمن السيبراني ONCD في البيت الأبيض تقريراً بعنوان [Back to the Building Blocks](https://bidenwhitehouse.archives.gov/oncd/briefing-room/2024/02/26/press-release-technical-report/?ref=arabroot.io)، يقول فيه إن الشركات تستطيع أن تمنع فئات كاملة من الثغرات باستخدام لغات آمنة للذاكرة، ويذكر C وC++ بالاسم كمثالين على لغات تفتقد هذه الصفة ومنتشرة في الأنظمة الحساسة. والجزء الذي يغفل عنه أغلب من نقل الخبر أن [التقرير نفسه](https://bidenwhitehouse.archives.gov/wp-content/uploads/2024/02/Final-ONCD-Technical-Report.pdf?ref=arabroot.io) يناقش أنظمة الفضاء كحالة خاصة، ويقول إن أكثر اللغات استخداماً فيها اليوم هي C وC++، وإن Rust تملك الصفات المطلوبة لكنها لم تثبت بعد في أنظمة الفضاء، ولذلك يقترح معها حلولاً في العتاد Hardware والطرق الرياضية الرسمية Formal Methods. أي أن الوثيقة الأشهر نفسها تعترف بأن الانتقال ليس ممكناً في كل مكان الآن. ### يوليو 2024: DARPA تبحث في ترجمة C إلى Rust في 31 يوليو 2024 أعلنت DARPA، وهي وكالة الأبحاث التابعة لوزارة الدفاع، عن برنامج بحثي اسمه [TRACTOR](https://www.darpa.mil/research/programs/translating-all-c-to-rust?ref=arabroot.io)، اختصاراً لـ Translating All C to Rust، وهدفه كما في [إعلان الوكالة](https://www.darpa.mil/news/2024/memory-safety-vulnerabilities?ref=arabroot.io) أن تصبح ترجمة كود C القديم إلى Rust آلية، بجودة قريبة مما يكتبه مبرمج Rust خبير، بالجمع بين التحليل الثابت والديناميكي ونماذج اللغة الكبيرة LLMs. وقال مدير البرنامج حينها إنك تستطيع اليوم أن تطلب من أي نموذج محادثة ترجمة كود C إلى Rust، والنتيجة «غالباً جيدة جداً، ولكن ليس دائماً»، وهذه الفجوة هي موضوع البحث. وهذا برنامج أبحاث بعقود مع جامعات وشركات، وليس أمراً لأحد بأن يترجم كوده. ### أكتوبر 2024: «ممارسات سيئة» وموعد 2026 في أكتوبر 2024 نشرت CISA ومعها FBI وثيقة [Product Security Bad Practices](https://www.cisa.gov/resources-tools/resources/product-security-bad-practices?ref=arabroot.io)، وهي أشد الوثائق لهجة، فهي تصف تطوير خطوط منتجات جديدة تستخدم في البنية التحتية الحساسة بلغة غير آمنة للذاكرة، مثل C أو C++، عندما تتوفر بدائل آمنة جاهزة، بأنه «خطير» ويرفع المخاطر على الأمن الوطني. وفي [الإصدار الأول](https://www.cisa.gov/sites/default/files/2024-10/joint-guidance-product-security-bad-practices-508c.pdf?ref=arabroot.io) طلبت من الشركات أن تنشر خارطة طريق لأمان الذاكرة قبل 1 يناير 2026، ثم في [الإصدار الثاني في يناير 2025](https://www.cisa.gov/sites/default/files/2025-01/joint-guidance-product-security-bad-practices-508c%5F0.pdf?ref=arabroot.io) أصبحت الصياغة «بنهاية 2025»، وأضيف استثناء للمنتجات التي أعلن عن انتهاء دعمها قبل 1 يناير 2030، وأضيفت ملاحظة تعترف بأن الانتقال يحتاج وقتاً وموارد كبيرة، وتقترح البدء بالكود الجديد مع تحصين القديم. وهذا هو الموعد الذي ينقله البعض على أنه «منع C++ في 2026»، والصحيح أنه موعد مقترح لنشر خطة، وليس موعداً لإيقاف لغة، والوثيقة تقول بوضوح إن ما فيها غير ملزم، وإنها لا تفرض على أحد أن يتجنب هذه الممارسات. ولكن يجب أن تعرف أن الوثائق غير الملزمة لها أثر عملي، فالجهات الحكومية والشركات الكبيرة قد تضعها في شروط الشراء وأسئلة تقييم الموردين، فإذا كنت تبيع منتجاً لهذه الجهات فتوقع أن يسألك أحدهم عن خطتك. ### يونيو 2025: دليل عملي من NSA وCISA وفي 24 يونيو 2025 نشرت NSA وCISA معاً دليلاً بعنوان [Memory Safe Languages: Reducing Vulnerabilities in Modern Software Development](https://www.cisa.gov/resources-tools/resources/memory-safe-languages-reducing-vulnerabilities-modern-software-development?ref=arabroot.io)، وهو أقل حدة من سابقه وأكثر عملية، فهو يتحدث عن العوائق الحقيقية أمام الانتقال وكيف تتعامل معها: الحمايات على مستوى اللغة، ودعم المكتبات، والأدوات، وتدريب المطورين. والجدول التالي يلخص هذه الوثائق: | التاريخ | الجهة | الوثيقة | ماذا تطلب | ملزمة؟ | | ----------------------- | ------------------------ | --------------------------------- | ------------------------------------------------------------------ | ------------------ | | نوفمبر 2022 | NSA | Software Memory Safety | التفكير في التحول إلى لغة آمنة عندما يكون ممكناً | لا، توصية | | ديسمبر 2023 | CISA وNSA وFBI وأربع دول | The Case for Memory Safe Roadmaps | نشر خارطة طريق لأمان الذاكرة | لا، توصية | | فبراير 2024 | البيت الأبيض ONCD | Back to the Building Blocks | اللغات الآمنة للكود الجديد، والعتاد والطرق الرسمية حيث لا يمكن ذلك | لا، تقرير | | يوليو 2024 | DARPA | TRACTOR | بحث في الترجمة الآلية من C إلى Rust | لا، برنامج بحثي | | أكتوبر 2024 ويناير 2025 | CISA وFBI | Product Security Bad Practices | عدم بدء منتجات حساسة جديدة بلغة غير آمنة، وخارطة طريق بنهاية 2025 | لا، تقول ذلك صراحة | | يونيو 2025 | NSA وCISA | Memory Safe Languages | كيف تتجاوز عوائق الانتقال | لا، دليل | ## ماذا فعلت الشركات؟ التوصيات وحدها لا تقنع أحداً، والذي جعل هذا الموضوع جاداً هو الأرقام التي نشرتها الشركات بعد أن بدأت فعلاً، وأهمها تجربة Android. ### Android: الكود الجديد أولاً بدأ فريق Android كما يقول في [مقال سبتمبر 2024](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?ref=arabroot.io) بتوجيه التطوير الجديد إلى لغات آمنة للذاكرة، Rust للكود منخفض المستوى وJava وKotlin لغيره، في حدود 2019، ولم يحاول أن يعيد كتابة الكود القديم. والنتيجة كانت كما يلي: | السنة | نسبة ثغرات الذاكرة من كل ثغرات Android | المصدر | | ----- | -------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------- | | 2019 | 76% | [مدونة Google للأمن، ديسمبر 2022](https://security.googleblog.com/2022/12/memory-safe-languages-in-android-13.html?ref=arabroot.io) | | 2022 | 35% | المصدر نفسه | | 2024 | 24% | [مدونة Google للأمن، سبتمبر 2024](https://security.googleblog.com/2024/09/eliminating-memory-safety-vulnerabilities-Android.html?ref=arabroot.io) | | 2025 | أقل من 20% لأول مرة | [مدونة Google، نوفمبر 2025](https://blog.google/security/rust-in-android-move-fast-fix-things/?ref=arabroot.io) | والسؤال الطبيعي هنا: كيف تنخفض النسبة بهذا الشكل بينما أغلب كود Android ما زال C وC++؟ والإجابة التي يشرحها الفريق أن الثغرات تتركز في الكود الجديد، والكود القديم الذي يعمل منذ سنوات تكتشف أغلب أخطائه وتصلح مع الوقت، فإذا توقفت عن إضافة كود جديد غير آمن، فإن مصدر الثغرات الجديدة يجف تدريجياً حتى لو بقي الكود القديم كما هو. وفي [مقال نوفمبر 2025](https://blog.google/security/rust-in-android-move-fast-fix-things/?ref=arabroot.io) ذكر الفريق أن في Android نحو 5 ملايين سطر Rust، وأن كثافة ثغرات الذاكرة فيها تقدر بنحو 0.2 ثغرة لكل مليون سطر، مقابل نحو 1000 لكل مليون سطر في تاريخ كود C وC++ عندهم، وأن نسبة التراجع Rollback عن تغييرات Rust المتوسطة والكبيرة أقل بنحو 4 مرات من C++، وأن تغييراتها تقضي وقتاً أقل بنحو 25% في المراجعة. وفي المقال نفسه قصة صادقة تستحق الذكر، فالفريق كاد أن ينشر أول ثغرة ذاكرة في كود Rust، وهي تجاوز حدود في مكتبة CrabbyAVIF لقراءة الصور، أخذت الرقم CVE-2025-48530 واكتشفت قبل أن تصل إلى أي إصدار عام. والدرس هو ما رأيناه في التجربة: Rust تقلل المساحة التي يجب أن تراجعها بعناية، ولكنها لا تلغيها. ### Rust في نواة Linux دخل دعم Rust إلى نواة Linux في [دمج Linus Torvalds بتاريخ 3 أكتوبر 2022](https://github.com/torvalds/linux/commit/8aebac82933ff1a7c8eede18cab11e1115e2062b?ref=arabroot.io)، وكان ذلك في دورة الإصدار 6.1، وكان حينها الحد الأدنى فقط الذي يسمح بترجمة كود Rust داخل النواة، والهدف كتابة برامج التعريف Drivers الجديدة بها. ولم يكن الطريق هادئاً، ففي يناير 2025 رفض Christoph Hellwig، وهو من مطوري طبقة DMA، طلب إضافة واجهات Rust لها، كما تروي [LWN](https://lwn.net/Articles/1006805/?ref=arabroot.io)، وقال إنه لا يريد لغة ثانية في هذا الجزء من النواة، حتى لو تولى غيره صيانتها، ويوضح فريق Rust for Linux في [سياسة مكتوبة](https://rust-for-linux.com/rust-kernel-policy?ref=arabroot.io) أن كل نظام فرعي Subsystem في النواة يقرر بنفسه كيف يتعامل مع Rust، فبعضها يقبل كود Rust ويصونه بنفسه، وبعضها يتركه لغيره. ثم في ديسمبر 2025 ناقشت [قمة مطوري النواة Maintainers Summit](https://lwn.net/Articles/1049831/?ref=arabroot.io) وضع التجربة، وكان الاتفاق كما تنقل LWN أن Rust في النواة لم تعد تجربة وأصبحت جزءاً أساسياً منها، وذكر Miguel Ojeda في [الجلسة نفسها](https://lwn.net/Articles/1050174/?ref=arabroot.io) أن أجهزة Android 16 التي تعمل بالنواة 6.12 تشحن وحدة ashmem المكتوبة بلغة Rust، أي أن ملايين الأجهزة الحقيقية تشغل اليوم كود Rust داخل النواة، ولاحظ أن النواة نفسها ما زالت C، والذي تغير هو أن الكود الجديد في بعض الأجزاء أصبح يكتب بلغة أخرى. ### Microsoft وWindows بعد مقال الـ 70% نشر فريق MSRC في يوليو 2019 مقالاً آخر بعنوان [Why Rust for safe systems programming](https://www.microsoft.com/en-us/msrc/blog/2019/07/why-rust-for-safe-systems-programming?ref=arabroot.io) يشرح فيه لماذا يرى Rust أنسب خيار لكتابة كود الأنظمة الآمن، ثم في يوليو 2023 ذكرت [نشرة Windows 11 Insider Preview Build 25905](https://blogs.windows.com/windows-insider/2023/07/12/announcing-windows-11-insider-preview-build-25905/?ref=arabroot.io) أن هذا الإصدار التجريبي فيه أول جزء من نواة Windows مكتوب بلغة Rust الآمنة، وهو الملف `win32kbase_rs.sys` الذي يحتوي تطبيقاً جديداً لمناطق الرسم GDI Region، ووصفته بأنه تجربة صغيرة. ### Cloudflare وAmazon في سبتمبر 2022 كتبت Cloudflare عن [Pingora](https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/?ref=arabroot.io)، وهو ال Proxy الذي بنته بلغة Rust بدلاً من NGINX، وذكرت أنه يخدم أكثر من تريليون طلب يومياً بثلث استهلاك المعالج والذاكرة السابق، وأن الخدمة لم تسقط بسبب كود الخدمة نفسه منذ بدايتها. وفي Amazon بني [Firecracker](https://github.com/firecracker-microvm/firecracker?ref=arabroot.io)، وهو مدير الأجهزة الافتراضية الصغيرة microVM الذي يشغل AWS Lambda وAWS Fargate، بلغة Rust، و[صفحة المشروع](https://firecracker-microvm.github.io/?ref=arabroot.io) تذكر أنه بدأ من crosvm، وهو مدير أجهزة افتراضية مكتوب بلغة Rust في Chromium OS. ⚠️ أمان الذاكرة لا يعني أن البرنامج صحيح، ففي 18 نوفمبر 2025 تعطل جزء كبير من خدمات Cloudflare، وكما في [تقرير الحادثة](https://blog.cloudflare.com/18-november-2025-outage/?ref=arabroot.io) فإن تغييراً في صلاحيات قاعدة بيانات جعل ملف إعدادات يستخدمه نظام Bot Management يتضاعف حجمه، ووصل الملف إلى ال Proxy الجديد FL2 المكتوب بلغة Rust، فتجاوز حداً لحجمه في الكود، وكان الكود يستدعي `unwrap()` على النتيجة دون أن يتعامل مع حالة الخطأ، فتوقفت الخدمة بـ Panic وظهرت أخطاء 5xx للمستخدمين. فلم تكن هناك ثغرة ذاكرة، ولكن الخدمة سقطت، لذلك تعامل مع الأخطاء في Rust صراحة ولا تستخدم `unwrap()` في مسار الإنتاج. ## وماذا يقول عالم C++؟ لم يقف مجتمع C++ صامتاً، ولكنه أيضاً لم يتفق على طريق واحد، والقرار في النهاية للجنة المعايير ISO WG21 التي شرحنا طريقة عملها في [مقال مواصفات اللغات](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%87%D8%A7-%D9%88%D8%AD%D9%88%D9%83%D9%85%D8%AA%D9%87%D8%A7/#c-cpp). ### Stroustrup وفكرة ال Profiles بعد أقل من شهر على نشرة NSA كتب Bjarne Stroustrup، صاحب C++، ورقة للجنة بتاريخ 6 ديسمبر 2022 بعنوان [A call to action: Think seriously about "safety"; then do something sensible about it](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2739r0.pdf?ref=arabroot.io)، اعترض فيها على أن النشرة تضع C وC++ في سلة واحدة باسم «C/C++» وتتجاهل ثلاثين سنة من التطور، وقال إن الأمان أوسع من أمان الذاكرة، ولكنه في الورقة نفسها دعا اللجنة إلى أن تأخذ الموضوع بجدية. واقتراحه هو ال Profiles، أي مجموعات من القواعد تفعلها على ملف أو مشروع، فيرفض المترجم ما يخالفها، مثل بعض العمليات الخطرة على المؤشرات، ويضيف فحوصاً أثناء التشغيل حيث يلزم، مع بقاء كودك القديم يعمل كما هو. وتطور الاقتراح في أوراق مثل [P3274 A framework for Profiles development](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3274r0.pdf?ref=arabroot.io) في مايو 2024، ثم [P3984 A type-safety profile](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2026/p3984r0.pdf?ref=arabroot.io) في فبراير 2026. ### اقتراح Safe C++ وما حدث له الطريق الآخر قدمه Sean Baxter، صاحب المترجم Circle، في الورقة [P3390 Safe C++](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3390r0.html?ref=arabroot.io) بتاريخ 12 سبتمبر 2024، وفكرته أن تضيف إلى C++ نفسها ما في Rust: Borrow Checker، ودوالاً تعلم بالكلمة `safe` لا تستدعي كوداً غير آمن إلا داخل كتلة `unsafe` صريحة، ومكتبة قياسية جديدة آمنة باسم `std2`، مع بقاء كود C++ الحالي يترجم كما هو، وقد طبق ذلك فعلاً في Circle. وفي اجتماع اللجنة في نوفمبر 2024 صوتت مجموعة الأمان SG23 على أي الطريقين له الأولوية، وكانت النتيجة كما في [تقرير Herb Sutter](https://herbsutter.com/2024/11/24/wg21-2024-11/?ref=arabroot.io) 19 صوتاً لأولوية ال Profiles، و11 لكلا الطريقين، و6 على الحياد، و9 لأولوية Safe C++، ووافقت مجموعة تطوير اللغة في الاجتماع نفسه على [P3466](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3466r1.pdf?ref=arabroot.io) كمبادئ مكتوبة لتصميم اللغة، ومنها تجنب العلامات التي تنتشر إجبارياً في كل الكود Viral Annotations، والمثال الذي تذكره هو بالضبط دالة آمنة لا تستطيع إلا أن تستدعي دوالاً آمنة. ومنذ ذلك الوقت لا توجد مراجعة جديدة لورقة Safe C++ في قوائم أوراق اللجنة لعامي 2025 و2026، أي أن الاقتراح توقف داخل اللجنة، والطريق الذي تسير فيه C++ اليوم هو تقليل السلوك غير المعرف وال Profiles. ### ما الذي دخل C++26 فعلاً؟ في مارس 2026 أنهت اللجنة العمل التقني على C++26، وكما في [تقرير الاجتماع](https://herbsutter.com/2026/03/29/c26-is-done-trip-report-march-2026-iso-c-standards-meeting-london-croydon-uk/?ref=arabroot.io) فيها تحسينان في أمان الذاكرة تحصل عليهما بإعادة الترجمة فقط: قراءة متغير محلي لم تعطه قيمة لم تعد سلوكاً غير معرف، وإنما أصبحت ما تسميه اللجنة Erroneous Behavior، أي خطأ في البرنامج لكن نتيجته محددة ولا يستغلها المترجم في التحسين، ومكتبة قياسية محصنة Hardened Standard Library بالورقة [P3471](https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p3471r3.html?ref=arabroot.io)، تفحص الحدود في عمليات مثل `vector` و`span` و`string` و`string_view`. أما ال Profiles فلم تدخل C++26، والعمل عليها مستمر بهدف C++29، وفي [اجتماع يونيو 2026](https://herbsutter.com/2026/06/13/brno-trip-report/?ref=arabroot.io) كان أمان الذاكرة وال Profiles من أهم موضوعات الإصدار القادم. والخلاصة هنا أن C++ لن تختفي، فهي في المتصفحات وقواعد البيانات والألعاب والأنظمة المالية ومترجمات اللغات الأخرى نفسها، وتقرير البيت الأبيض نفسه يعترف بأن بعض الأنظمة لا تستطيع الانتقال الآن، ولكن C++ أيضاً لا تقدم اليوم ضماناً على مستوى اللغة مثل Rust، وإنما أدوات تقلل الخطأ، وهي موضوع القسم التالي. ## تحصين C وC++ اليوم إذا كان عندك كود C أو C++ لن تعيد كتابته، وهذا حال أغلب الشركات، فالخطوة الأولى رخيصة جداً: إعدادات المترجم والمكتبات. لنبدأ بالبرنامج `bugs.c` نفسه مع الماكرو [\_FORTIFY\_SOURCE](https://man7.org/linux/man-pages/man7/feature%5Ftest%5Fmacros.7.html?ref=arabroot.io) الذي يجعل glibc تفحص حجم الوجهة في دوال مثل `strcpy` و`memcpy` عندما يعرفه المترجم: ```bash docker run --rm --name lab-memsafe-c -v "$PWD":/w -w /w gcc:16.2.0 sh -c 'gcc -O2 -D_FORTIFY_SOURCE=3 -o /tmp/bugs bugs.c 2>/dev/null && /tmp/bugs overflow guest; /tmp/bugs overflow AAAAAAAAB; echo "exit code: $?"' ``` والمخرج سوف يكون كما يلي: ``` overflow: name=guest is_admin=0 *** buffer overflow detected ***: terminated Aborted (core dumped) exit code: 134 ``` لاحظ أن الاسم القصير عمل كالمعتاد، أما الاسم الطويل فقد أوقف البرنامج برسالة `buffer overflow detected` بدلاً من أن يعطي المستخدم صلاحية المدير، والسبب أن المترجم يعرف أن `acc.name` حجمها 8 بايتات فيمرر هذا الحجم إلى نسخة محمية من `strcpy`. ولكن هذا الفحص يعمل فقط مع التحسين `-O1` فما فوق، وفقط عندما يعرف المترجم حجم الوجهة، فهو شبكة أمان وليس ضماناً. الأداة الثانية هي أدوات الفحص أثناء التشغيل Sanitizers، وأشهرها [AddressSanitizer](https://clang.llvm.org/docs/AddressSanitizer.html?ref=arabroot.io) واختصاراً ASan، وهي تضيف فحصاً حول كل وصول إلى الذاكرة: ```bash docker run --rm --name lab-memsafe-c -v "$PWD":/w -w /w -e ASAN_OPTIONS=detect_leaks=0 gcc:16.2.0 sh -c 'gcc -g -fsanitize=address -o /tmp/bugs bugs.c 2>/dev/null && /tmp/bugs uaf 2>&1 | sed -n "1,/^SUMMARY/p"' ``` والمخرج سوف يكون كما يلي: ``` ================================================================= ==12==ERROR: AddressSanitizer: heap-use-after-free on address 0x7b8c6cbe0010 at pc 0x7f6c6ddc3560 bp 0x7ffc1889f470 sp 0x7ffc1889ec30 READ of size 2 at 0x7b8c6cbe0010 thread T0 #0 0x7f6c6ddc355f (/usr/local/lib64/libasan.so.8+0xcb55f) #1 0x7f6c6dde408a in vprintf (/usr/local/lib64/libasan.so.8+0xec08a) #2 0x7f6c6dde6084 in printf (/usr/local/lib64/libasan.so.8+0xee084) #3 0x000000401403 in use_after_free /w/bugs.c:24 #4 0x000000401510 in main /w/bugs.c:39 #5 0x7f6c6db2dca7 (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: 5e5b51f4c39af9ac589408c1dc432ba390a273cc) #6 0x7f6c6db2dd64 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29d64) (BuildId: 5e5b51f4c39af9ac589408c1dc432ba390a273cc) #7 0x000000401140 in _start (/tmp/bugs+0x401140) 0x7b8c6cbe0010 is located 0 bytes inside of 16-byte region [0x7b8c6cbe0010,0x7b8c6cbe0020) freed by thread T0 here: #0 0x7f6c6de1b40f (/usr/local/lib64/libasan.so.8+0x12340f) #1 0x0000004013c9 in use_after_free /w/bugs.c:21 #2 0x000000401510 in main /w/bugs.c:39 #3 0x7f6c6db2dca7 (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: 5e5b51f4c39af9ac589408c1dc432ba390a273cc) previously allocated by thread T0 here: #0 0x7f6c6de1c35f in malloc (/usr/local/lib64/libasan.so.8+0x12435f) #1 0x0000004013a3 in use_after_free /w/bugs.c:19 #2 0x000000401510 in main /w/bugs.c:39 #3 0x7f6c6db2dca7 (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: 5e5b51f4c39af9ac589408c1dc432ba390a273cc) SUMMARY: AddressSanitizer: heap-use-after-free /w/bugs.c:24 in use_after_free ``` لاحظ أن التقرير يذكر نوع الخطأ `heap-use-after-free`، والسطر الذي قرأ فيه البرنامج الذاكرة المحررة (24)، والسطر الذي حررها (21)، والسطر الذي حجزها (19)، وهذه المعلومات الثلاث تختصر ساعات من البحث. ولكن توثيق ASan يذكر أن البرنامج يبطؤ في المتوسط إلى النصف، ولذلك مكانه الاختبارات وخط CI/CD والاختبار بالمدخلات العشوائية Fuzzing، وليس السيرفر الحقيقي، وهذا الفرق مهم: ASan يكتشف الخطأ إذا حدث أثناء الاختبار، أما Rust فتمنعه قبل التشغيل في كل الحالات. وفي C++ تستطيع أن تجعل المكتبة القياسية نفسها تفحص الحدود، وهذا الملف `vec.cpp` يكتب في عنصر من `std::vector` برقم يأتي من سطر الأوامر: ```cpp #include #include #include int main(int argc, char **argv) { std::vector prices{10, 20, 30}; int i = argc > 1 ? std::atoi(argv[1]) : 0; prices[i] = 99; // operator[] does not check the index by default std::printf("prices[%d]=%d size=%zu\n", i, prices[i], prices.size()); return 0; } ``` الآن نقوم بترجمته بالطريقة العادية ونكتب في العنصر رقم 1000 من مصفوفة فيها ثلاثة عناصر: ```bash docker run --rm --name lab-memsafe-cpp -v "$PWD":/w -w /w gcc:16.2.0 sh -c 'g++ -O2 -o /tmp/vec vec.cpp && /tmp/vec 1000; echo "exit code: $?"' ``` ``` prices[1000]=99 size=3 exit code: 0 ``` البرنامج كتب الرقم 99 في مكان ما من ال Heap خارج المصفوفة، ثم قرأه وطبعه، وأنهى عمله برمز خروج 0 وكأن كل شيء سليم. والآن نفس الكود مع الخيار [\-fhardened](https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html?ref=arabroot.io) الذي أضيف في GCC 14، وهو خيار واحد يفعل مجموعة من إعدادات التحصين دون أن يغير ال ABI: ```bash docker run --rm --name lab-memsafe-cpp -v "$PWD":/w -w /w gcc:16.2.0 sh -c 'g++ -O2 -fhardened -o /tmp/vec vec.cpp && /tmp/vec 1; /tmp/vec 1000; echo "exit code: $?"; g++ --help=hardened' ``` والمخرج سوف يكون كما يلي: ``` prices[1]=99 size=3 /usr/local/include/c++/16.2.0/bits/stl_vector.h:1253: constexpr std::vector<_Tp, _Alloc>::reference std::vector<_Tp, _Alloc>::operator[](size_type) [with _Tp = int; _Alloc = std::allocator; reference = int&; size_type = long unsigned int]: Assertion '__n < this->size()' failed. Aborted (core dumped) exit code: 134 The following options are enabled by -fhardened: -D_FORTIFY_SOURCE=3 (or =2 for glibc < 2.35) -D_GLIBCXX_ASSERTIONS -ftrivial-auto-var-init=zero -fPIE -pie -Wl,-z,now -Wl,-z,relro -fstack-protector-strong -fstack-clash-protection -fcf-protection=full ``` في المخرج أعلاه لاحظ التالي: - الفهرس الصحيح 1 عمل كالمعتاد، والفهرس 1000 أوقف البرنامج برسالة واضحة `Assertion '__n < this->size()' failed` في `operator[]`، والسبب هو [\_GLIBCXX\_ASSERTIONS](https://gcc.gnu.org/onlinedocs/libstdc++/manual/using%5Fmacros.html?ref=arabroot.io) الذي يفعل فحص الحدود في مكتبة libstdc++. - قائمة الخيارات تبين ما يفعله `-fhardened`: `_FORTIFY_SOURCE=3` الذي رأيناه، وإعطاء المتغيرات المحلية قيمة صفر تلقائياً `-ftrivial-auto-var-init=zero`، وحماية ال Stack، وحماية تدفق التنفيذ `-fcf-protection`، وغيرها. - إذا كنت تستخدم Clang مع مكتبة libc++ فالمقابل هو [أوضاع التحصين Hardening Modes](https://libcxx.llvm.org/Hardening.html?ref=arabroot.io)، والتوثيق يوصي أغلب المشاريع بالوضع `fast` في الإنتاج لأنه يحتوي الفحوص الأمنية الأهم بتكلفة قليلة، والوضع `extensive` لمن يريد فحوصاً أكثر بعد قياس الأداء. وللقائمة الكاملة من الخيارات وشرح كل واحد منها راجع [دليل OpenSSF لتحصين خيارات المترجم في C وC++](https://best.openssf.org/Compiler-Hardening-Guides/Compiler-Options-Hardening-Guide-for-C-and-C++.html?ref=arabroot.io). ولاحظ أن كل هذه الأدوات تحول الخطأ الصامت إلى توقف واضح، وهذا تحسن كبير، ولكنها لا تجعل اللغة آمنة للذاكرة، فالفحص يعمل على الحالات التي يعرفها فقط، والاستخدام بعد التحرير في الإنتاج لا تمنعه أي من هذه الإعدادات. وعندما تنتهي من التجربة قم بحذف ال Images التي نزلتها إذا لم تعد تحتاجها، فال Containers نفسها حذفت بعد كل أمر بسبب `--rm`: ```bash docker rmi gcc:16.2.0 rust:1.99.0-slim-trixie ``` ## ماذا يعني هذا لك؟ بعد كل ما سبق قد يتساءل البعض: هل يجب أن أتعلم Rust الآن؟ والإجابة تعتمد على الكود الذي تكتبه، والصورة التالية تبين الطرق الثلاثة: ![سؤال في الأعلى What code are you writing يتفرع إلى ثلاث لوحات: على اليمين تطبيقات الأعمال وال APIs بلغات C# وJava وGo وPython وJS ولديك أمان الذاكرة اليوم ولا تحتاج إعادة كتابة، وفي الوسط الكود الجديد منخفض المستوى حيث تناسب Rust مثل المحللات وخدمات الشبكة وبرامج التعريف، وعلى اليسار كود C وC++ الكبير الموجود فتبقيه وتحصنه بخيار -fhardened والمكتبة المحصنة وASan وFuzzing في CI وتكتب الأجزاء الجديدة بلغة آمنة](https://arabroot.io/content/images/2026/10/memory-safety-rust-04-choose.webp) أغلب المطورين يملكون أمان الذاكرة اليوم، والسؤال الحقيقي هو أين تكتب الكود منخفض المستوى الجديد - **إذا كنت تكتب بلغة C# أو Java أو Go أو Python أو JavaScript:** فأنت تستخدم لغة آمنة للذاكرة، فالأربع الأولى في قائمة NSA نفسها، وJavaScript مثلها تدير الذاكرة عنك، ولا يوجد شيء تعيد كتابته. والذي يجب أن تنتبه له هو الكود الذي يخرج عن هذه الضمانات: `unsafe` في C#، و`cgo` و`unsafe` في Go، والمكتبات الأصلية Native Libraries التي يستدعيها تطبيقك، مثل مكتبات الصور والضغط، فهذه مكتوبة غالباً بلغة C، وثغرة libwebp أصابت تطبيقات كثيرة بهذه الطريقة، ولذلك يبقى تحديث الاعتماديات كما شرحنا في [أمن سلسلة التوريد البرمجية](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) جزءاً من أمان الذاكرة عندك. - **إذا كنت ستكتب كوداً جديداً منخفض المستوى:** مثل محلل لصيغة ملفات، أو خدمة شبكة تستقبل بيانات من الإنترنت، أو Agent يعمل على أجهزة العملاء، أو برنامج تعريف، أو نظام مدمج لا يحتمل جامع قمامة، فهنا تناسب Rust، وهذا بالضبط ما فعلته Android وLinux. والثمن حقيقي: منحنى تعلم أصعب في البداية بسبب ال Borrow Checker، ووقت ترجمة أطول، ومكتبات أقل في بعض المجالات، وفريق يحتاج تدريباً. - **إذا كان عندك كود C أو C++ كبير يعمل:** فلا تقم بإعادة كتابته كله، والسبب أن إعادة الكتابة الكاملة تأخذ سنوات وتضيف أخطاء جديدة، وتجربة Android تبين أن الكود القديم المستقر ليس مصدر أغلب الثغرات. قم بتفعيل `-fhardened` أو ما يقابله، وقم بتفعيل تحصين المكتبة القياسية، وشغل ASan والاختبار بالمدخلات العشوائية في CI، واكتب الأجزاء الجديدة المعرضة للشبكة بلغة آمنة إذا كانت الواجهة بينها وبين القديم سهلة. - **إذا كنت تبيع برمجيات لجهات حكومية أو بنية تحتية حساسة:** فاكتب خارطة طريق لأمان الذاكرة حتى لو لم يطلبها أحد منك بعد، فهي وثيقة قصيرة تقول ما هي لغات منتجك اليوم، وأي الأجزاء تتعامل مع مدخلات غير موثوقة، وما الذي سوف تفعله بها وبأي ترتيب. والجدول التالي يلخص المقارنة: | | C/C++ دون تحصين | C/C++ مع التحصين | Rust | C# وJava وGo | | --------------------- | -------------------- | ---------------------------------- | ------------------------------- | ----------------------------- | | تجاوز الحدود | صامت غالباً | يتوقف في الحالات التي يعرفها الفحص | Panic عند التشغيل، أو خطأ ترجمة | استثناء Exception عند التشغيل | | الاستخدام بعد التحرير | صامت | ASan في الاختبار فقط | خطأ ترجمة | غير ممكن، جامع القمامة يقرر | | التحرير مرتين | أحياناً تكتشفه glibc | ASan في الاختبار فقط | خطأ ترجمة | غير ممكن | | جامع قمامة | لا يوجد | لا يوجد | لا يوجد | يوجد | | الخروج عن الضمانات | كل الكود | كل الكود | داخل unsafe فقط | unsafe والمكتبات الأصلية | ## تدريب عملي - غير الرقم 16 في `malloc(16)` الثانية في الدالة `use_after_free` إلى 64، وأعد تشغيل التجربة الأولى، ولاحظ هل ما زال المؤشر القديم يقرأ `attacker-data`، ثم فكر لماذا. - ابحث في مشروعك عن كل مكتبة أصلية Native Library يستدعيها تطبيقك، وتأكد من إصدارها، وهل صدر لها تحديث أمني في آخر سنة. - إذا كان عندك مشروع C أو C++، أضف `-fhardened` إلى بناء الاختبارات أولاً، وشغل الاختبارات، وانظر هل يتوقف شيء. ## الخلاصة وصلنا لنهاية الموضوع، وأهم ما فيه: - لا يوجد قرار من وزارة الدفاع الأمريكية بمنع C++، والذي صدر توصيات من NSA وCISA وFBI والبيت الأبيض، وبرنامج بحثي من DARPA، وكلها غير ملزمة. - أخطاء الذاكرة نحو 70% من الثغرات في منتجات Microsoft ومن الثغرات الخطيرة في Chromium، وهي منتجات أغلبها بلغتي C وC++، وأشهرها تجاوز الحدود والاستخدام بعد التحرير والتحرير مرتين. - في C مرت الأخطاء الثلاثة بتحذيرات فقط، وتغيرت نتيجتها مع التحسين، أما Rust فرفضت البرنامج قبل التشغيل، وأوقفت تجاوز الحدود بـ Panic، ولكنها لا تحميك داخل `unsafe`. - Android وجهت الكود الجديد إلى لغات آمنة، فانخفضت نسبة ثغرات الذاكرة من 76% في 2019 إلى أقل من 20% في 2025، وRust لم تعد تجربة في نواة Linux. - C++ باقية، وC++26 جاءت بمكتبة محصنة وسلوك أقل غموضاً، وال Profiles في الطريق لإصدار C++29، واقتراح Safe C++ توقف في اللجنة. - إذا كنت تكتب بلغة C# أو Java أو Go فأنت آمن للذاكرة اليوم، وإذا كتبت كوداً منخفض المستوى جديداً ففكر في Rust، وإذا كان عندك C++ كبير فحصنه ولا تعد كتابته. وفي مرحلة [لغات البرمجة](https://arabroot.io/start/#stage-programming) نفسها سوف نتحدث بإذن الله عن إدارة الذاكرة بالتفصيل، يدوياً أم بجامع القمامة أم بالملكية في Rust، وعن كيف تختار لغة لمشروعك بقرار عملي بعيداً عن الحماس. [![](https://arabroot.io/content/images/2026/10/memory-basics-cover-cover.webp)دليلالذاكرة للمبرمجين: كيف تعمل ال Stack وال Heapلماذا تتغير قائمة لم تطلب تغييرها، وكيف تتسرب الذاكرة في لغة فيها جامع قمامة Garbage Collector، بأمثلة حقيقية من عدة لغات.](https://arabroot.io/articles/%D8%A7%D9%84%D8%B0%D8%A7%D9%83%D8%B1%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D9%86-stack-%D9%88-heap-%D9%88%D8%A7%D9%84%D9%85%D8%A4%D8%B4%D8%B1%D8%A7%D8%AA/)[![](https://arabroot.io/content/images/2026/10/paradigms-types-cover-cover.webp)دليلأنماط البرمجة وأنظمة الأنواع: لماذا تختلف اللغات؟نحل مسألة واحدة بعدة أساليب برمجة، ونرى هل تكتشف اللغة أخطاءك قبل التشغيل أم بعده، وماذا يعني ذلك عند اختيار لغة لمشروعك.](https://arabroot.io/articles/%D8%A7%D9%86%D9%85%D8%A7%D8%B7-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%A7%D9%86%D8%B8%D9%85%D8%A9-%D8%A7%D9%84%D8%A7%D9%86%D9%88%D8%A7%D8%B9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/language-creators-cover-cover.webp)دليلقصص لغات البرمجة ومن صنعها، من Fortran إلى Rustمن صنع اللغات التي نكتب بها كل يوم، وما المشكلة التي دفعته إلى ذلك، وكيف تشرح قصة كل لغة قراراتها.](https://arabroot.io/articles/%D9%82%D8%B5%D8%B5-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D9%85%D9%86-%D8%B5%D9%86%D8%B9%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/language-specs-cover-cover.webp)دليلاللغة شيء والمترجم شيء آخر: من يقرر مستقبل لغات البرمجة؟لماذا لا تصح جمل مثل «Python بطيئة»، وما الفرق بين مواصفة اللغة والبرامج التي تطبقها، ومن يقرر مستقبلها.](https://arabroot.io/articles/%D9%85%D9%88%D8%A7%D8%B5%D9%81%D8%A7%D8%AA-%D9%84%D8%BA%D8%A7%D8%AA-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D9%88%D8%AA%D8%B7%D8%A8%D9%8A%D9%82%D8%A7%D8%AA%D9%87%D8%A7-%D9%88%D8%AD%D9%88%D9%83%D9%85%D8%AA%D9%87%D8%A7/)[![](https://arabroot.io/content/images/2026/10/secure-coding-cover-cover.webp)دليلالبرمجة الآمنة Secure Coding بأمثلة من أربع لغاتكيف تكتب الكود الذي يتعامل مع مدخلات المستخدم والملفات والأخطاء بحيث لا يحتاج إصلاحاً أمنياً لاحقاً، بأمثلة في أربع لغات.](https://arabroot.io/articles/%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D8%A9-%D8%A7%D9%84%D8%A7%D9%85%D9%86%D8%A9-secure-coding-%D9%84%D9%84%D9%85%D8%B7%D9%88%D8%B1%D9%8A%D9%86/)[![](https://arabroot.io/content/images/2026/10/supply-chain-cover-cover.webp)دليلأمن سلسلة التوريد البرمجية Software Supply Chain للمبتدئينكل ما بين كود غيرك وسيرفرك قد يحمل كود المهاجم، وهنا تعرف التهديدات الحقيقية بحوادث موثقة والدفاع المناسب لكل حلقة.](https://arabroot.io/articles/%D8%A7%D9%85%D9%86-%D8%B3%D9%84%D8%B3%D9%84%D8%A9-%D8%A7%D9%84%D8%AA%D9%88%D8%B1%D9%8A%D8%AF-%D8%A7%D9%84%D8%A8%D8%B1%D9%85%D8%AC%D9%8A%D8%A9-%D9%84%D9%84%D9%85%D8%A8%D8%AA%D8%AF%D8%A6%D9%8A%D9%86/) ## سجل التحديثات - أكتوبر 2026: كتابة المقال، وتشغيل كل الأمثلة في Containers باستخدام gcc:16.2.0 (GCC 16.2.0 وglibc 2.41) وrust:1.99.0-slim-trixie (rustc 1.99.0)، ومراجعة كل التواريخ والأرقام من الوثائق الأصلية.