اكتشاف الكود الميت في مشروع C/C++ القديم [مغلق]

Question

كيف يمكنك اكتشاف التعليمات البرمجية الميتة في كود C/C++؟لدي قاعدة تعليمات برمجية كبيرة جدًا للعمل بها، وما لا يقل عن 10-15% منها عبارة عن تعليمات برمجية ميتة.هل هناك أي أداة تعتمد على Unix لتحديد هذه المناطق؟لا تزال بعض أجزاء التعليمات البرمجية تستخدم الكثير من المعالجات المسبقة، فهل يمكن للعملية الآلية التعامل مع ذلك؟

Answer 1

هل يمكن استخدام أداة تحليل تغطية رمز لهذا والبحث عن النقاط غير المستخدمة في التعليمات البرمجية.

وهناك أداة شعبية ل toolchain دول مجلس التعاون الخليجي gcov، جنبا إلى جنب مع lcov الواجهة الرسومية ( HTTP: / /ltp.sourceforge.net/coverage/lcov.php ).

إذا كنت تستخدم دول مجلس التعاون الخليجي، يمكنك تجميع بدعم gcov، التي مكنت من العلم "--coverage. بعد ذلك، تشغيل التطبيق الخاص بك أو تشغيل اختبار جناح الخاص بك مع هذه gcov تمكين البناء.

وأساسا دول مجلس التعاون الخليجي سوف تنبعث منها بعض الملفات الإضافية خلال تجميع وسيقوم التطبيق أيضا تنبعث بعض بيانات التغطية في الوقت الحالي. لديك لجمع كل هذه (.gcdo و.gcda الملفات). أنا لا أذهب في التفاصيل الكاملة هنا، ولكن ربما كنت بحاجة إلى تعيين متغيرات البيئة اثنين لجمع بيانات التغطية بطريقة سليمة: GCOV_PREFIX وGCOV_PREFIX_STRIP ...

وبعد تشغيل، يمكنك وضع جميع بيانات التغطية معا وتشغيله من خلال toolsuite lcov. دمج جميع ملفات تغطية من اختباراته المختلفة من الممكن أيضا، وإن كان ينطوي على بعض الشيء.

وعلى أية حال، كنت في نهاية المطاف مع مجموعة لطيفة من صفحات الويب تظهر بعض المعلومات التغطية، لافتا إلى قطعة من التعليمات البرمجية التي ليس لها التغطية وبالتالي، لم تستخدم.

وخرجت عن مسارها، تحتاج لمضاعفة التحقق إذا لم يتم استخدام أجزاء من التعليمات البرمجية في أي حالة والكثير يعتمد على كيفية جيدة ممارسة الاختبارات الخاصة بك مصدر برنامج. ولكن على الأقل، وهذا سيعطي فكرة عن المرشحين رمز ميت ممكن ...

Answer 2

وتجميع تحت دول مجلس التعاون الخليجي مع رمز -Wunreachable.

وأعتقد أن أكثر حداثة من الإصدار نتائج أفضل ستحصل، ولكن قد أكون مخطئا في انطباعي أنه شيء لقد تم العمل بنشاط على. لاحظ أن هذا لا تتدفق التحليل، لكنني لا أعتقد أنه يخبرك عن "كود" الذي مات بالفعل بحلول الوقت الذي يترك المعالج، لأن ذلك أبدا تحليل من قبل المجمع. فإنه سيتم أيضا لم يكشف على سبيل المثال وظائف تصديرها والتي تسمى أبدا، أو حالة خاصة لمعالجة التعليمات البرمجية التي يحدث فقط حتى أن من المستحيل لأن لا شيء يدعو من أي وقت مضى وظيفة مع تلك المعلمة - تحتاج تغطية رمز لذلك (وتشغيل الاختبارات الوظيفية، وليس وحدة الاختبارات اختبارات وحدة من المفترض ل٪ من التغطية قانون 100، وبالتالي تنفيذ مسارات كود وهي "القتلى" بقدر ما يكون التطبيق المعني). ومع ذلك، مع هذه القيود في الاعتبار انها وسيلة سهلة للبدء إيجاد إجراءات أكثر bollixed تماما في قانون الأساس.

هذه استشارية CERT يسرد بعض الأدوات الأخرى بالنسبة لساكنة كود الكشف عن وفاة

Answer 3

يعتمد أسلوبك على اختبارات التوفر (الآلية).إذا كان لديك مجموعة اختبار تثق بها لتغطية قدر كافٍ من الوظائف، فيمكنك استخدام تحليل التغطية، كما اقترحت الإجابات السابقة بالفعل.

إذا لم تكن محظوظًا جدًا، فقد ترغب في البحث في أدوات تحليل التعليمات البرمجية المصدر مثل أدوات العلومافهم أن ذلك يمكن أن يساعدك في تحليل التعليمات البرمجية الخاصة بك باستخدام الكثير من تقارير التحليل المضمنة.تعود تجربتي مع هذه الأداة إلى عامين مضت، لذلك لا أستطيع أن أقدم لك الكثير من التفاصيل، ولكن ما أتذكره هو أنهم حصلوا على دعم مثير للإعجاب مع أوقات استجابة سريعة جدًا لإصلاحات الأخطاء والإجابات على الأسئلة.

لقد وجدت صفحة على تحليل كود المصدر الثابت الذي يسرد العديد من الأدوات الأخرى أيضًا.

إذا لم يساعدك ذلك بشكل كافٍ أيضًا، وكنت مهتمًا بشكل خاص بمعرفة الكود الميت المتعلق بالمعالج المسبق، فإنني أوصيك بنشر المزيد من التفاصيل حول الكود.على سبيل المثال، إذا كان الأمر يتعلق في الغالب بمجموعات مختلفة من إعدادات #ifdef، فيمكنك كتابة نصوص برمجية لتحديد الإعدادات (مجموعات) ومعرفة المجموعات التي لم يتم إنشاؤها فعليًا أبدًا، وما إلى ذلك.

Answer 4

وز ++ 4.01 -Wunreachable رمز يحذر من التعليمات البرمجية التي لا يمكن الوصول إليه في وظيفة، ولكن لا يحذر حول وظائف غير المستخدمة.

int foo() { 
    return 21; // point a
}

int bar() {
  int a = 7;
  return a;
  a += 9;  // point b
  return a;
}

int main(int, char **) {
    return bar();
}

وز ++ 4.01 سيصدر تحذيرا حول النقطة ب، ولكن أقول شيئا عن فو () (النقطة أ) على الرغم من أنها غير قابلة للوصول في هذا الملف. هذا السلوك هو الصحيح على الرغم من خيبة الأمل، لأن المترجم لا يمكن أن نعرف أن فو () وظيفة لم يتم التصريح خارجي في بعض وحدة تجميع الأخرى واستدعاء من هناك. فقط رابط يمكن أن يكون متأكدا.

Answer 5

لكود C فقط وعلى افتراض أن شفرة المصدر من المشروع بأكمله غير متاح، وإطلاق تحليل مع أداة مفتوحة المصدر FRAMA-C . أي بيان من البرنامج الذي يعرض الحمراء في واجهة المستخدم الرسومية هو كود ميتا.

إذا كان لديك مشاكل "مدونة ميت"، قد تكون مهتمة ايضا في إزالة "مدونة الفراغ"، رمز التي يتم تنفيذها ولكن لا المساهمة في النتيجة النهائية. وهذا يتطلب منك أن تقدم وmodelization دقيقة من وظائف I / O (كنت لا تريد لإزالة حساب الذي يبدو أن "قطع" ولكن يستخدم كحجة لprintf). FRAMA-C ديها خيار لافتا كود الفراغ.

Answer 6

موزيلا و <لأ href = "http://www.csn.ul.ie /~caolan/Packages/callcatcher.html "يختلط =" نوفولو noreferrer "> فتح مكتب دينا حلول نابعة من الداخل.

Answer 7

يتطلب تحليل الكود الميت مثل هذا تحليلًا عالميًا لمشروعك بأكمله.لا يمكنك الحصول على هذه المعلومات من خلال تحليل وحدات الترجمة بشكل فردي (حسنًا، يمكنك اكتشاف الكيانات الميتة إذا كانت موجودة بالكامل ضمن وحدة ترجمة واحدة، لكنني لا أعتقد أن هذا ما تبحث عنه حقًا).

لقد استخدمنا مجموعة أدوات إعادة هندسة برمجيات DMS الخاصة بنا لتنفيذ هذا بالضبط لرمز Java، عن طريق تحليل جميع وحدات الترجمة المعنية في وقت واحد، وبناء جداول الرموز لكل شيء ومطاردة جميع المراجع.لقد انتهى تعريف المستوى الأعلى الذي لا يحتوي على مراجع ولا يدعي أنه عنصر خارجي لواجهة برمجة التطبيقات (API).تقوم هذه الأداة أيضًا بإزالة الكود الميت تلقائيًا، وفي النهاية يمكنك اختيار ما تريد:تقرير الكيانات الميتة، أو الكود المجرد من تلك الكيانات.

يقوم DMS أيضًا بتحليل لغة C++ في مجموعة متنوعة من اللهجات (تحرير فبراير 2014: بما في ذلك إصدارات MS وGC من C++ 14 [تحرير نوفمبر 2017:الآن C++ 17]) ويبني جميع جداول الرموز الضرورية.سيكون تعقب المراجع الميتة أمرًا مباشرًا من تلك النقطة.يمكن أيضًا استخدام DMS لتجريدهم.يرى http://www.semanticdesigns.com/Products/DMS/DMSToolkit.html

Answer 8

نقطة الهدف أداة تغطية من شأنه أن يساعد. انها ليست حرة بالرغم من ذلك.