Nezávislá recenze PVS-Studio (Linux, C++)

Viděl jsem příspěvek o tom, že PVS konečně naučil analyzovat pod Linuxy, a rozhodl jsem se to vyzkoušet na svých projektech. A to, co z toho vzešlo.

Obsah

1. Výhody
2. Nevýhody
3. Závěry
4. Poznámka na závěr

Výhody

Reagující podpora

Požádal jsem o zkušební klíč a ten mi byl zaslán ještě tentýž den.

Dostatečně srozumitelná dokumentace

Spustit analyzátor se podařilo bez větších problémů. Nápověda k příkazům v konzoli je také k dispozici (i když zde jsou určité výhrady, viz oddíl Nevýhody).

Možnost vícthreadové analýzy

Analyzátor má „standardní“ možnost -j, která umožňuje provádět analýzu paralelně v několika úlohách. To výrazně šetří čas.

Dobrá vizualizace

Mnoho různých formátů výstupu, od textového po malou webovou verzi. Webová verze je pohodlná, lakonická, s nápovědou vedle řádků v kódu a odkazy na popisky diagnostiky.

Jednoduchá integrace do sestavení

Veškerá dokumentace je na jejich webu, mohu jen říct, že pokud váš projekt je sestavován pomocí CMake, je to velmi jednoduché.

Dobré popisy diagnostiky

Pokud generujete výstup v režimu fullhtml, pak má každá zpráva odkaz na popis diagnostiky, s vysvětleními, příklady kódu a dalšími odkazy.

Nevýhody

Nedostatek znalosti jazyka C++ analyzátorem

Bohužel, PVS občas chybně interpretuje syntaxi a generuje falešně pozitivní zprávy při zcela správném kódu.

Například, existuje funkce, která vrací 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));
}

Ano, klíčové slovo auto může znamenat void, na to je auto. Ale PVS vyhodil následující zprávy:

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.

Velmi pomalý web

Ano, v webové verzi je vedle každé zprávy odkaz na příslušný popis diagnostiky s příklady. Ale při kliknutí na odkaz je čekání dost dlouhé a někdy to znamená i 504 Gateway Time-out.

Jazyk

Všechny popisy jsou v ruštině, což je skvělé. Ale odkazy z zprávy vždy vedou na anglickou verzi. Bylo by dobré mít možnost přepínat jazyk, abych mohl diagnostiky ihned prohlížet v ruštině. Takovou možnost jsem v rozhraní nenašel.

Nepraktické práce s úrovněmi diagnostiky prostřednictvím konzole

Začněme tím, že dvě použitá týmy (to je pvs-studio-analyzer a plog-converter) mají různé formáty zadání diagnostiky.

Nápověda k pvs-studio-analyzer praví:

-a [MODE], --analysis-mode [MODE]
    MODE určuje typ varování:
    1 - 64-bitové chyby;
    2 - rezervováno;
    4 - Obecná analýza;
    8 - Mikrooptimalizace;
    16 - Specifické požadavky zákazníků;
    32 - MISRA.
    Módy mohou být kombinovány sečtením hodnot
    Výchozí: 4

Dlouho jsem se snažil pochopit, kam je tedy třeba přidávat („adding the values“) klíče. Snažil jsem se je uvádět odděleně čárkou:

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

Snažil jsem se zapsat klíč několikrát:

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

A až poté jsem si uvědomil, že to jsou bitové masky! A je třeba sečíst, a ne přidávat hodnoty. Například, abych získal obecné diagnostiky, diagnostiky pro mikrooptimalizace a MISRA, je třeba je sečíst (4 + 8 + 32 = 44):

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

Používání bitových masek v uživatelských rozhraních je obvykle špatný zvyk. To vše bylo možné sečíst i uvnitř, a uživateli nastavit sadu příznaků.

Kromě toho existuje ještě utilita plog-converter, která generuje čitelné informace o statické analýze. Má jiné zádrhele.

Nápověda k programu plog-converter oznamuje:

-a, --analyzer            Určuje analyzátor(y) a úroveň(e), které
                          mají být použity pro filtrování, tj.
                          'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                          Výchozí: GA:1,2

Objevily se zde nějaké „úrovně“, které předtím nikde nebyly, a v dokumentaci jsem o nich také nic nenašel.

Obecně vzato, není to jasné. Proto jsem všechno nastavoval na maximum.

Hromada zbytečného nadávání na Catch

Ve dvou ze tří projektů, které jsem analyzoval, se používá knihovna pro modulové testování Catch2. A převážná část zpráv (!!! 90 ze 138 v jednom a 297 ze 344 v druhém !!!) má následující podobu:

Nezohledňuje vícerozměrnost

Spousta falešně pozitivních upozornění o údajně neměnných proměnných nebo nekonečných smyčkách, přičemž se s těmito proměnnými pracuje z různých vláken, a kdyby tomu tak nebylo, moduly by nespouštěly testy.

Nicméně, může vůbec taková situace být zohledněna statickým analyzátorem? Nevím.

Závěry

PVS nenalezl žádnou skutečnou chybu v mých otevřených projektech Burst a Proxima, a také v pracovním projektu, který z pochopitelných důvodů nemohu předložit. Nicméně je třeba mít na paměti, že některé nedostatky již byly dříve odhaleny a opraveny. Cppcheck a scan-build.

Celkový dojem ze všech těchto analyzátorů je zhruba stejný: ano, něco zachytí, někdy dokonce něco důležitého, ale celkově je kompilátor dostatečný.

Možná (a mě osobně těší si to myslet), že náš tým používá takové postupy vývoje softwaru, které umožňují generovat minimální množství špatného kódu. Lépe je nevytvářet problémy, než je pak hrdinně překonávat.

Proto si dovoluji poskytnout několik rad, jak psát v jazyce C++, abyste si nikomu neseřízli nohy a neudeřili se do čela.

Využívejte diagnostiku kompilátoru naplno

Náš tým používá (a doporučuje vám) následující možnosti kompilace:

-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

Začleňte je do svého projektu, objevíte mnoho nového o svém kódu.

Dodgejte se standardu

Snažte se nepoužívat věci závislé na platformě, pokud mají standardní analogy, a pokud se bez nich opravdu nelze obejít, zabalte je do speciálních bloků pod makro (nebo jinak) a jednoduše nedovolte, aby se váš kód kompiloval v nepodporovaných podmínkách.

Držte se standardní sémantiky operací

Sčítání by mělo být sčítáním, násobení - násobením, volání funkce - voláním funkce, kopírování by mělo kopírovat, přesun - přesunout, kontejner by měl být iterovatelný, iterátor by měl mít posun ++ a dereferencování *. A tak dále, a tak dále.

Myslím, že myšlenka je jasná. Existují ustálené dohody, které nejsou povinné, ale které by měly očekávat všichni uživatelé a čtenáři vašeho kódu. Nesnažte se obelstít ostatní, jinak podvedete sami sebe.

Píšete kompatibilní kód

V první řadě myslím na standardní knihovnu. Velmi žádoucí je, aby rozhraní vašich tříd a funkcí mohla být použita se standardními i jinými knihovnami (například Boostem).

Nebojte se nakouknout do rozhraní STL a Boost. S výjimkou vzácných případů tam uvidíte důstojný příklad pro napodobování.

Využívejte otevřené nástroje naplno.

Pro stejnou statickou analýzu existují alespoň dva otevřené bezplatné nástroje, které se jednou připojují k jakémukoli projektu se systémem sestavení CMake.

Více o tom si můžete přečíst v mém nedávném příspěvku..

Poznámka na závěr

Na závěr zdůrazňuji, že nezavrhuji použití PVS nebo jakýchkoli jiných statických analyzátorů. Ale vyzývám k zamyšlení, jak je možné, že statický analyzátor neustále nachází ve vašem kódu zásadní chyby.

To je pouze důsledek. Je potřeba hledat a odstraňovat příčinu.

Zdroj: habr.com