PVS-Studio зізнається в любові до Linux

PVS-Studio зізнається в любові до LinuxЦе замітка про кохання. Про кохання статичного аналізатора коду PVS-Studio чудовою відкритої операційної системи Linux. Ця любов молода, зворушлива і ранима. Цієї любові потрібно допомогти зміцнитися. Ви допоможете, якщо заздалегідь запишіться в добровольці для тестування бета-версії PVS-Studio for Linux.

Я і мої колеги дуже довго відмовлялися обговорювати тему розробки PVS-Studio для операційної системи Linux і UNIX світу в цілому. Справа не в якихось особистих пристрастях або технічних труднощах. Все простіше — це холодний, прагматичний підхід до розвитку продукту.

Ми — маленька компанія, яка існує виключно за рахунок продажу програмного продукту PVS-Studio. Ми не отримуємо гранти або якусь іншу підтримку від держави або великих компаній — все це накладає велику відповідальність за вибір напрямку розвитку.

Зараз ми накопичили нових сил, зібралися з духом і починаємо нову для нас тему освоєння Linux. Так, так, це сталося. Ми зважилися почати роботи в цьому напрямку. Сподіваюся, з цим у нас вийде краще, ніж з CppCat.

PVS-Studio for Windows
Спочатку коротко нагадаю, що зараз являє собою PVS-Studio, і що він вміє на даний момент. Якщо Ви вже читали наші статті, то можете пропустити цей розділ.

PVS-Studio — це інструмент для виявлення помилок у вихідному коді програм, написаних на мовах С, C++ і C#. Аналізатор до цього моменту був орієнтований на розробників, які використовують середовище Visual Studio. Підтримувані мови і діалекти:
  • Visual Studio 2015: C, C++, C++/CLI, C++/CX (WinRT), C#
  • Visual Studio 2013: C, C++, C++/CLI, C++/CX (WinRT), C#
  • Visual Studio 2012: C, C++, C++/CLI, C++/CX (WinRT), C#
  • Visual Studio 2010: C, C++, C++/CLI, C#
  • MinGW (частково): C, C++
Основні особливості PVS-Studio:
  • Автоматичний аналіз файли після перекомпіляції в Visual Studio.
  • Збереження і завантаження результатів аналізу: вночі можна перевірити код, зберегти результати, а вранці завантажити їх і дивитися.
  • Запуск з командного рядка для перевірки всього рішення: дозволяє інтегрувати PVS-Studio в нічні збірки, щоб вранці у всіх був свіжий лог.
  • Mark as False Alarm – розмітка в коді, щоб не лаятися конкретної діагностикою в конкретному фрагменті файлу.
  • Mass Suppression – придушити всі старі повідомлення, щоб аналізатор видавав 0 спрацьовувань. До них завжди можна повернутися пізніше. Зручне впровадження. Помилки лише в новому коді.
  • Використання відносних шляхів у файлах звіту для можливості перенесення звіту на іншу машину.
  • CLMonitoring – перевірка проектів, у яких немає файлів Visual Studio (.sln/.vcxproj); якщо вам не вистачить функціональності CLMonitoring, то ви можете інтегрувати PVS-Studio в будь-яку Makefile-based систему збирання вручну.
  • Хороша масштабованість: аналізатор може завантажити всі ядра процесора. Додатково можна використовувати спільно з IncrediBuild.
Детальніше познайомитися з аналізатором, а також завантажити його можна на сторінці продукту PVS-Studio. Наостанок наведу зведену таблицю основних діагностичних можливостей PVS-Studio. У таблицю включені не всі діагностики, так як деякі з них складно класифікувати. Це не завадить скласти загальне враження, а докладно з наявними діагностиками можна познайомитися тут.

Таблиця 1 - Можливості PVS-Studio. Натисніть на зображення для його збільшення.
Таблиця 1 — Можливості PVS-Studio. Натисніть на зображення для його збільшення.

PVS-Studio for Linux
Тепер, власне, поговоримо про те, заради чого багато хто почали читати цю статтю: про підтримку Linux.

PVS-Studio love Linux

Це завдання не так проста, як може здаватися на перший погляд. Скомпілювати виконуваний модуль під Linux і що-то з його допомогою перевірити — завдання нехитра. Ми давно з нею впоралися. Ще рік тому ми писали статтю про експерименті про перевірку Vim. Однак, це лише маленька частина всього обсягу робіт. Програмісти забувають, що зібрати виконуваний модуль і створити програмний продукт — це далеко не одне і теж.

Ми плануємо підтримати GCC і Clang. Ми почали з GCC, а до Clang ми повернемося пізніше. Розповім про завдання, які зараз стоять перед нами.

1. Більш повна підтримка GCC і Clang
Мені іноді здається, що розробникам компіляторів нудно, і вони придумують різні способи зробити собі життя складніше, а заодно і розробникам, які реалізують підсвічування коду, статичний аналіз і так далі. Іншим способом я не можу пояснити навіщо, наприклад, знадобилося вводити Conditionals with Omitted Operands. Звичайно, круто, що можна скоротити тернарний оператор до: z = x?: y;. На мій погляд, без цього абсолютно спокійно можна обійтися і жити щасливим життям.

Багатьох дивує, чому треба морочитися з різними документованими і недокументированными розширеннями компілятора. Здається, досить аналізувати С++, відповідний стандарту і не звертати увагу на розширення, так як вони використовуються вкрай рідко. На жаль, це не так, і розширень доводиться приділяти багато часу.

Не важливо, часто чи ні зустрічаються в програмі нестандартні сутності. В будь-якій серйозній програмі зустрінуться відмінності файли, що містять будь-яке з розширень. В результаті це заплутує парсер в аналізаторі, і він не може повноцінно обробити безліч *.cpp файлів, у які включений цей злощасний *.h файл. Звичайно, в аналізаторі PVS-Studio вбудовані механізми, які намагаються компенсувати помилку розбору коду і продовжити аналіз. На жаль, цей механізм не завжди допомагає. В результаті можуть виникати дивні помилкові спрацьовування або навпаки, з аналізу виключено фрагмент коду (до кінця функції або класу, а то і всього файлу).

Більш того, всякі «хитрі» штучки люблять використовувати в системних заголовних файлах. Так що на практиці нарватися на якесь розширення дуже навіть легко.

Якщо комусь цікаво, про що все-таки йде мова, можу запропонувати поглянути, наприклад, на:І це тільки документовані розширення. З досвіду роботи з Visual З++, ми ще очікуємо наявність підлості у формі недокументованих розширень.

Оскільки ми використовуємо власний парсер (розвиток нині забутої і покинутої бібліотеки OpenC++), то ми повинні підтримати різні розширення.

Втім, використовуй ми якийсь інший парсер, це не сильно б нам допомогло. Наприклад, якщо ми перепишемо аналізатор, взявши за основу Clang, нам все одно доведеться самостійно боротися з розширенням GCC, Visual C++.

2. Нова система регресивних тестів в Linux
Розробляючи PVS-Studio, ми використовуємо сім методик тестування:
  1. Статичний аналіз коду на машинах розробників. У всіх розробників встановлений PVS-Studio. Новий або змінений код відразу перевіряється з допомогою механізму інкрементального аналізу. Перевіряється C++ і С# код.
  2. Статичний аналіз коду при нічних збірках. Якщо попередження не було помічено, то воно виявиться на етапі нічний складання на сервері. PVS-Studio перевіряє C# C++ код. Крім цього, ми додатково використовуємо Clang для перевірки C++ коду. Один час для C# коду також додатково застосовувався FxCop. Протягом року він так жодного разу нічого не знайшов корисного, і ми відмовилися від його використання. А ось Clang пару раз знаходив помилки, які не помічав PVS-Studio, і ми визнали раціональним продовжувати його використовувати.
  3. Юніт-тести рівня класів, методів, функцій. Не дуже розвинена система, так як багато моментів складно тестувати із-за необхідності готувати для тіста великий об'єм вхідних даних. Більше ми покладаємося на високорівневі тести.
  4. Функціональні тести рівня спеціально підготовлених та розмічених файлів з помилками.
  5. Функціональні тести, які підтверджують, що ми коректно розбираємо системні відмінності файли. Це важливо, тому що якщо в системному файлі використовуються нестандартні розширення, то це псує перевірку відразу багатьох проектів.
  6. Регресійні тести рівня окремих сторонніх проектів і рішень (projects and solutions) — самий важливий і корисний для нас вид тестування. Для його здійснення ми регулярно перевіряємо 105 відкритих проектів на C++ і 49 на C#. Порівнюючи старі та нові результати аналізу, ми контролюємо, що щось не зламали і відточуємо нові діагностичні повідомлення.
  7. Функціональні тести користувальницького інтерфейсу. Мається на увазі тестування розширення (plug-in), яка інтегрується в середовище Visual Studio. Перевіряємо, що натискання на різні кнопки і пункти меню призводить до потрібних результатів.
З точки зору підтримки Linux, нам потрібно в першу чергу розширити пункт N5 і N6. Пункт N5 перетинається з попереднім розділом «Більш повна підтримка GCC і Clang». Зробити тести для перевірки системних заголовних файлів нескладно, але важко розширювати парсер. Втім, про це ми вже говорили, і набагато цікавіше пункт N6.

Насправді, це найбільша і найскладніша з використовуваних у нас система тестування. Ось, як виглядає ця програма в процесі роботи:

Система тестування

Описувати цей інструмент у статті сенсу немає, так як він призначений виключно для внутрішнього використання. Скажу тільки, що він дозволяє дуже зручно відстежувати розробникам результати їх правок у ядрі аналізатора і додавання нових діагностик.

Так от, тепер нам належить створити аналог такої системи для Linux. Оскільки це дуже важлива частина процесу розробки аналізатора, ми повинні підійти до цього завдання з усією серйозністю. Так само нам потрібно буде провести велику роботу з підбору відкритих проектів, на яких і буде здійснюватися перевірка працездатності аналізатора. З одного боку, ці проекти не повинні бути занадто великі, щоб не зробити час перевірки занадто довгим. З іншого, вони повинні бути «насиченими»: у різних проектах мають використовуватися різні підходи до програмування. Тобто, бажано, щоб десь активно застосовувалися оператори goto, де активно використовувалися шаблони, де активно працювали з Unicode і так далі. Це робить тестування аналізатора більш всебічним. Зібрати таку колекцію исходников досить непросте завдання, що вимагає час на вивчення великої кількості відкритих проектів.

3. Моніторинг компіляторів
До складу PVS-Studio для Windows йде GUI утиліта Standalone.exe. З її допомогою можна зручно працювати зі звітами (*.plog-файлами), якщо не встановлено середовище розробки Visual Studio:

PVS-Studio Standalone Tool

Але це не головне. Важливіше те, що за допомогою цієї утиліти можна перевірити проект, що складається будь екзотичної або самописною складальної системою. Втім, це не призначається саме для екзотичних ситуацій. Навіть якщо у вас класичний makefile, простіше виконати аналіз з допомогою Standalone, ніж розбиратися з документацією PVS-Studio, щоб прописати в maklefile виклик аналізатора.

Standalone дозволяє відстежувати запуски компіляторів Visual C++, GCC (MinGW), Clang і збирати всю необхідну для перевірки інформацію. Виглядає це наступним чином: ви говорите програмі «почати стеження», після чого виконуєте звичайну складання проекту. Далі ви кажете програмі «готово». Починається аналіз всіх тих файлів, компіляція яких тільки що виконувалась.

До речі, все це не обов'язково робити вручну. Ви можете використовувати для перевірки проекту на сервері консольну утиліту CLMonitor.exe. Вона також збирає інформацію про запущені компіляторів і виконує перевірку проекту.

Реалізуючи Linux версію, ми відразу вирішили, що обов'язково треба підтримати відстеження запусків компілятора. Це допоможе програмістам швидше і простіше знайомитися з аналізатором PVS-Studio. Справа в тому, що, використовуючи цю утиліту, проект зможе перевірити будь-який член команди, не відволікаючи людей, що займаються підтримкою makefile-ів і взагалі системи складання. У великих проектах далеко не кожен знає, як власне збирається їх застосування. Тим більше, не кожен знайде час і бажання розбиратися, як і куди прописати виклик PVS-Studio. Все це ще може бути ускладнене наявністю автогенерируемого makefile. Зрозуміло, що в усьому можна розібратися, але це є суттєвим бар'єром на шляху першої перевірки проекту та задоволення дослідного цікавості.

Ось ви і познайомилися з ще однією підзавданням створення Linux-версії. Ми працюємо над розробкою системи моніторингу запусків компіляторів і складанням всієї необхідної інформації для перевірки.

4. Доопрацювання документації
При написанні документації ми завжди стикаємося з протилежними бажаннями. З одного боку, ми завжди намагалися, щоб продукт залишався простим і зрозумілим, і для роботи з ним не потрібно було знайомитися з великим керівництвом. З іншого боку, статичний аналіз — це досить складний інструмент, і в керівництві повинні бути відображені всі тонкощі роботи з ним. Особливо це стосується опису діагностичних повідомлень: їх багато, і треба щоб кожне з них було детально описано та супроводжувалося прикладами коду.

В результаті нам належить велика робота по коригуванню і поповненню документації розділів, присвячених роботі в Linux. Плюс, нам треба придумати, як реалізувати можливість користувачам швидко отримувати інформацію з тієї чи іншої діагностиці. У Visual Studio з цим немає проблем — досить натиснути в списку попереджень на код помилки і відкриється відповідна сторінка.

Як і що запропонувати в середовищі Linux — треба думати. Звичайно, завжди є PDF файл (на 350 сторінок) або online документація на сайті, але це не можна назвати зручним способом доступу до опису діагностик.

5. Доопрацювання сайту
Сайт, природно, теж потребує доопрацювання. Це не программистская завдання, але займатися нею треба, тому я вирішив згадати сайт в навчальних цілях. Багато програмісти думають тільки про коді і забувають, що у випуску продукту бере участь багато інших колег, які вирішують велику кількість прихованих від них завдань.

6. Інше: тестування, дистрибутив, організація підтримки
Звісно, не треба забувати про тестування. Хоча багаторівневі тести виявлять більшість проблем, напевно проявлять себе якісь абсолютно несподівані помилки або недоробки. Зараз навіть неможливо припустити, що це буде, але ми не маємо ілюзій про ідеальність світу. Під Windows ми зіткнулися з різноманітними ситуаціями, коли начебто і не ми винні, але щось працює неправильно. Про деякі таких неприємних несподіванки я розповідав інтерв'ю близько 2 років тому (шукайте у статті фразу «На жаль, вся краса і надійність внутрішнього коду іноді розвалюється через впливів ворожого навколишнього середовища»). Впевнений, Linux нас чекають аналогічні сюрпризи.

Результати нашої роботи треба обернути в дистрибутив, який можна легко завантажити і використовувати. Сказати це набагато простіше, ніж зробити. Думаю, знадобиться не одна ітерація, щоб зробити зручним і врахувати різні тонкощі.

І останнє: ми повинні організувати підтримку нового напряму. Наші користувачі цінують нас за якісну та оперативну підтримку. З виходом Linux версії збільшиться кількість запитів, особливо спочатку, коли далеко не все буде працювати, і ми повинні бути до цього готові.

7. Плани на майбутнє
Вище я описав-далеко не все, на що нам потрібно буде витратити час, щоб адаптувати PVS-Studio Linux. Є безліч більш дрібних завдань, про які відразу не згадаєш, так і писати про них нецікаво. Наприклад, мені треба написати цю та багато інших статей, які розкажуть людям про те, що з'явився PVS-Studio для Linux.

Є й великі завдання, якими ми займемося пізніше. Наприклад, як я вже говорив, спочатку ми зосередилися на GCC, і тільки потім плануємо позайматися з Clang. Я поки навіть не знаю, чи буде у першій релизной версії PVS-Studio для Linux підтримка Clang чи ні.

Ось ще деякі з великих завдань, які очікують нас:
  • Інтеграція з Qt Creator.
  • Інтеграція з… (час покаже).
  • Доопрацювання та вдосконалення діагностик. Наприклад, всередині PVS-Studio є таблиці з інформацією про типових функціях, таких як malloc, memset, std::swap. Ця інформація дозволяє виявляти багато помилок некоректно використання функцій. Варто розширити ці таблиці багатьма функціями, описаними в POSIX.
In progress
Вагітний єдиноріг

Ми з нетерпінням чекаємо, коли можна буде щось представити світу. Сподіваюся, я вас зацікавив, і багатьом Linux-розробникам хочеться спробувати перевірити свої проекти. Якщо у вас є бажання і час, запрошую вас заздалегідь вступити в групу бета-тестерів.

Отже, якщо ви хочете допомогти нам перевірити роботу PVS-Studio для Linux прошу написати нам. Щоб листи можна було простіше обробляти, просимо вказати в темі листа рядок «PVS-Studio for Linux, Beta». Листи надсилайте за адресою support@viva64.com. Просимо писати листи з корпоративних ящиків і коротко представитися. Ми будемо вдячні всім, хто відгукнеться, але в першу чергу будемо приділяти увагу тим людям, які потенційно згодом можуть стати нашими клієнтами.

Також прошу в листі дати відповіді на наступні питання:
  • Під якою операційною системою планується запускати аналізатор?
  • Яку середовище розробки ви використовуєте?
  • Який компілятор використовується для складання проекту?
  • Яку складальну систему ви використовуєте?
Коли з'явиться версія, яку можна буде спробувати, ми напишемо всім відгукнувся листи.

Заздалегідь дякую всім. Ми будемо часом згадувати в статтях, як просувається розвиток PVS-Studio для Linux. Бажаю всім рідше запускати відладчик!
Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.