З підвалу секретної лабораторії розробників PVS-Studio…, Блог розробників phpBB
Взагалі як користувача виглядає досконалий статичний аналізатор коду (у вакуумі чи ні)? Мені здається, на основі мого навички роботи в цій галузі, досконалий аналізатор має виглядати так. Користувач завантажує утиліту, запускає її, вказує папку з кодом і натискає величезну зелену кнопку: "Виявити всі помилки!". Жодної настройки, жодної «інтеграції в план». чай користувачеві це не потрібно? Так, не потрібно. Але необхідно аналізатор коду, на жаль. Як мінімум, необхідна інформація щодо #include і #define, якщо ми говоримо про C . Вона потрібна для того, щоб виконати препроцессування коду.
І тут ми приходимо до необхідності вибору одного з варіантів:
- Або інструмент повинен сам витягувати цю інформацію з плану (як роблять наші плагіни для Visual C і C Builder).
- Або інструмент може отримувати цю інформацію, якщо вона буде передана в Makefile (як працює наша версія для командного рядка).
- Або інструмент змушує користувача важко вбивати всі папки для #include і параметри #define, що приблизно немислимо, т.к. Користувачеві це зробити Винятково важко.
- Або ... придумати якийсь ще варіант.
Ми пішли четвертим шляхом і вирішили випробувати так. А якщо в якості початкової інформації аналізатор буде отримувати не прості вихідні коди у вигляді .cpp-файлів, а вже препроцесовані файли. Тобто. файли, оброблені препроцесором. Це нас позбавить необхідності викликати препроцесор, а відповідно знати ці #include і #define.
Безумовно, це трохи не збігається з описаним вище досконалим варіантом аналізатора. Але з іншого боку, це дозволяє використовувати PVS-Studio для практично будь-якого С/С проекту, в якому б середовищі розробки ви його не вели.
Виходить, інструмент, що розробляється в секретних лабораторіях нашої команди, виглядає приблизно так:
По-перше, ми вказуємо папку, де перепроцесовані .i-файли. Їх і досліджуватиме наш інструмент.
По-друге, ми вказуємо папку з вихідними джерелами. Це потрібно для того, щоб помилки виявляти більш правильно. Крім того, незмінно краще робити (надалі) навігацію по користувачам .cpp-файлам, а не по не зовсім виразним людині .i-файлам.
По-третє, ми вказуємо папку, де знаходяться системні include-файли. Найбільш базові, як або . Для чого? Щоб аналізатор знав, що тут лежать ті файли, на які видавати діагностичні повідомлення не потрібно.
Виходить, ми можемо «годувати» препроцесовані файли цієї програми, і потім вже на них запускати аналізатор. Саме таким чином ми й перевіряємо план Boost. До речі, незабаром буде звіт про перевірку Boost – підпишіться на наш блог, щоб не пропустити. Після перевірки файлів ми отримуємо список діагностичних повідомлень ось у такому вигляді:
Безумовно, цей пост не тягне на повноважний виклад нашої нової секретної утиліти. Втім на кілька питань я вже можу відповісти.
Кому не потрібна ця утиліта? Тим, хто спокійно може перевірити свій план у PVS-Studio з підтримкою інтеграції у Visual Studio та C Builder. Кому НЕОБХІДНА ця утиліта? Тим, хто хоче перевіряти свій код за допомогою PVS-Studio та використовує інші середовища розробки та/або проектні файли, в які важковбудувати нашу утиліту командного рядка.
Який би ви хотіли бачити таку утиліту? Чи комфортний вам режим перевірки готових препроцесованих файлів? Чого не вистачає у такій утиліті? Випускати нам її або закинути подальші розробки цієї утиліти, тому що всіх влаштовує наша інтеграція в середовища від Microsoft / Embarcadero?