Независим преглед на PVS-Studio (Linux, C++)

Видях публикуване за това, че PVS наистина е научил да анализира под Linux и реших да опитам на своите проекти. Ето какво се получи.

Съдържание

1. Плюсове
2. Недостатъци
3. Итог
4. Следсловие

Плюсове

Отзивчива поддръжка

Попитах за пробен ключ, в същия ден ми го изпратиха.

Достатъчно ясна документация

Успях да стартирам анализатора без особени проблеми. Съществува и помощ за конзолните команди (въпреки че тук има забележки, вижте раздела Недостатъци).

Възможност за многопоточен анализ

Анализаторът има "стандартна" опция -j, позволяваща да се извършва анализ паралелно в няколко задачи. Това спестява много време.

Добра визуализация

Много различни формати на изхода, от текстов до малък уеб интерфейс. Уеб интерфейсът е удобен, лаконичен, с подсказки до редовете в кода и линкове към описания на диагностика.

Лесна интеграция в компилацията

Цялата документация е на техния сайт, ще кажа само, че ако вашият проект се компилира с помощта на CMake, всичко е много просто.

Добри описания на диагностиките

Ако генерирате изхода в режим fullhtml, то всяко съобщение има линк към описанието на диагностика, със разяснения, примери за код и допълнителни линкове.

Недостатъци

Неизвестност на анализа от страна на анализатора по езика C++

За съжаление, PVS понякога греши в синтаксиса и генерира фалшиво положителни съобщения при напълно коректен код.

Например, има функция, която връща void:

template <typename T>
auto copy (const void * source, void * destination)
    ->
        std::enable_if_t
        <
            std::is_copy_constructible<T>::value
        >
{
    new (destination) T(*static_cast<const T *>(source));
}

Да, ключовото слово auto може да означава void, затова и е auto. Но PVS издаде следните съобщения:

dynamic_tuple_management.hpp:29:1: error: V591 Non-void function should return a value.
dynamic_tuple_management.hpp:29:1: error: V2542 Function with a non-void return type should return a value from all exit paths.

Много бавен сайт

Да, в уеб интерфейса до всяко съобщение има линк към съответното описание на диагностика с примери. Но при натискане на линка, чакането е доста дълго, а понякога се случва и 504 Gateway Time-out.

Език

Всички описания са на руски, което е отлично. Но линковете от отчета винаги водят към английската версия. Щеше да бъде добре да имате възможност да превключите езика, за да можете да разглеждате диагностика веднага на руски. В интерфейса не намерих такава възможност.

Неудобно е да се работи с нивата на диагностика чрез конзолата

Да започнем с това, че двете използвани команди (това е pvs-studio-analyzer и plog-converter) имат различни формати за задаване на диагностики.

Справката към pvs-studio-analyzer съобщава:

-a [MODE], --analysis-mode [MODE]
    MODE определя типа на предупрежденията:
    1 - 64-битови грешки;
    2 - запазено;
    4 - Обща Анализа;
    8 - Микрооптимизации;
    16 - Специфични Искания от Клиенти;
    32 - MISRA.
    Режимите могат да се комбинират чрез добавяне на стойностите.
    По подразбиране: 4

Дълго време се опитвах да разбера къде точно трябва да добавя («adding the values») ключовете. Опитвах се да ги изброявам с запетая:

pvs-studio-analyzer analyze ... -a 1,4,16

Опитвах се да напиша ключа няколко пъти:

pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16

И едва тогава ми хрумна, че това са битови маски! И трябва да съберете, а не добавя стойностите. Например, за да получите общи диагностики, диагностики по микрооптимизации и MISRA, трябва да ги съберете (4 + 8 + 32 = 44):

pvs-studio-analyzer analyze ... -a 44

Използването на битови маски в потребителските интерфейси обикновено е лош стил. Всичко това можеше да бъде сумирано и вътре, а на потребителя да се предостави набор от флагове.

Освен това, има и помощна програма plog-converter, която генерира човекочитаема информация за статичния анализ. Тя има свои специфични особености.

Справката към програмата plog-converter съобщава:

-a, --analyzer            Определя анализатор(и) и ниво(а), които да се
                          използват за филтриране, т.е.
                          'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                          По подразбиране: GA:1,2

Тук се появиха какви ли не «нива», които преди никъде не бяха споменавани, а и в документацията не намерих нищо за тях.

Общо взето, не е ясно. Затова всичко напълно го настройвах.

Куп неадекватни съобщения на Catch

В два от трите проекта, които анализирах, се използва библиотека за модулно тестване Catch2. И повечето съобщения (!!! 90 от 138 в един и 297 от 344 в друг !!!) имат следния вид:

Не отчита многопоточността

Много лъжливи положителни сработвания за уж неизменяеми променливи или безкрайни цикли, при положение че работата с тези променливи става от различни нишки, и ако не беше така, модулните тестове нямаше да сработват.

Въпреки това, може ли всъщност статичният анализатор да отчете нещо такова? Не знам.

Итог

PVS не откри нито една истинска грешка в моите отворени проекти Burst и Proxima, както и в работен проект, който по разбираеми причини не мога да представя. Вярно е, че някои недостатъци вече бяха открити и поправени преди време с помощта на Cppcheck и scan-build.

Общото впечатление от всички тези анализатори е почти същото: да, нещо хващат, понякога дори нещо важно, но в крайна сметка компилаторът е достатъчен.

Възможно е (и на мен ми е приятно да мисля така), че нашият екип използва практики за разработка на софтуер, които позволяват генерирането на минимално количество лош код. По-добре е да не създавате проблеми, отколкото героично да ги преодолявате.

Следователно поемам смелостта да дам няколко съвета как да пишете на C++ така, че да не стреляйте на себе си в краката и да не получавате удари по главата с граби.

Използвайте диагностиките на компилатора в максимална степен

Нашият екип използва (и ви съветва) следните опции за компилация:

-Werror

-Wall
-Wextra
-Wpedantic

-Wcast-align
-Wcast-qual
-Wconversion
-Wctor-dtor-privacy
-Wenum-compare
-Wfloat-equal
-Wnon-virtual-dtor
-Wold-style-cast
-Woverloaded-virtual
-Wredundant-decls
-Wsign-conversion
-Wsign-promo

Включете ги в проекта си, за да научите много ново за кода си.

Спазвайте стандарта

Опитайте се да не използвате зависимости от платформа, ако имате стандартни аналози, а ако наистина не можете да се справите без тях, обградете ги в специални блокове под макроси (или по друг начин) и просто не позволявайте кодът ви да се компилира в неподдържани условия.

Спазвайте стандартната семантика на операциите

Събиране трябва да бъде събиране, умножение — умножение, извикването на функция — извикване на функция, копирането трябва да копира, преместването — да премества, контейнерът трябва да бъде итерируем, а итераторът трябва да има напредък ++ и разыменование *. И така нататък, и така нататък.

Мисля, че мисълта е ясна. Има установени конвенции, които не са задължителни за спазване, но които всички потребители и читатели на вашия код очакват да видят. Не се опитвайте да надхитрите другите, иначе ще надхитрите сами себе си.

Пишете съвместим код

На първо място имам предвид стандартната библиотека. Много е желателно интерфейсите на вашите класове и функции да могат да се използват със стандартни и други библиотеки (например, Boost).

Не се колебайте да надзърнете в интерфейсите на STL и Boost. С изключение на редки случаи там ще видите достойни примери за подражание.

Използвайте максимално откритите инструменти

За същия статичен анализ съществуват поне два отворени безплатни инструмента, които се свързват с всеки проект с система за сглобяване CMake.

Повече по тази тема може да прочетете в моята récente публикация..

Следсловие

На финала ще подчертая, че не призовавам да не се използва PVS или каквито и да е други статични анализатори. Но призовавам да се замислите как е възможно статичният анализатор непрекъснато да открива съществени грешки във вашия код.

Това е само следствие. Трябва да се търси и отстранява причината.

Източник: habr.com