A PVS-Studio független felülvizsgálata (Linux, C++)

Láttam egy kiadványt, amelyet a PVS megtanult Linux alatt elemezni, és úgy döntöttem, hogy kipróbálom a saját projektjeimen. És ez jött ki belőle.

Tartalom

1. Érvek
2. Hátrányok
3. Eredményei
4. utószó

Érvek

Érzékeny támogatás

Próbakulcsot kértem, és még aznap elküldték.

Meglehetősen egyértelmű dokumentáció

Probléma nélkül sikerült elindítani az analizátort. A konzolparancsokhoz is elérhető súgó (bár van néhány panasz, lásd a részt Hátrányok).

Többszálú elemzés lehetősége

Az analizátornak van "standard" opciója -j, amely lehetővé teszi az elemzések párhuzamos elvégzését több feladatban. Ezzel sok időt takaríthatunk meg.

Jó vizualizáció

Számos különböző kimeneti formátum, a szövegtől a kis webkosárig. A webes felület kényelmes, tömör, a kód sorai mellett tippekkel és diagnosztikai leírásokra mutató hivatkozásokkal.

Könnyű beépítés az összeállításba

Az összes dokumentáció megtalálható a weboldalukon, csak azt tudom mondani, hogy ha a projekted CMake segítségével épül fel, akkor minden nagyon egyszerű.

Jó diagnosztikai leírások

Ha módban generál kimenetet fullhtml, akkor minden üzenethez tartozik egy hivatkozás a diagnosztikai leíráshoz, magyarázatokkal, kódpéldákkal és további hivatkozásokkal.

Hátrányok

Az analizátor nem ismeri a C++ nyelvet

Sajnos a PVS néha szintaktikai hibákat követ el, és hamis pozitív üzeneteket generál, ha a kód teljesen helyes.

Például van egy függvény, amely visszaadja 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));
}

Igen, kulcsszó auto Jelentheti void, erre való auto. De a PVS a következő üzeneteket produkálta:

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.

Nagyon lassú oldal

Igen, a webes felületen minden üzenet mellett található egy hivatkozás a megfelelő diagnosztikai leíráshoz példákkal. De ha rákattint egy linkre, akkor elég sokáig kell várni, és néha előfordul 504 kapu időtúllépés.

Nyelv

Minden leírás oroszul van, ami nagyszerű. De a jelentés linkjei mindig az angol változathoz vezetnek. Jó lenne, ha át lehetne váltani a nyelvet, hogy a diagnosztikát azonnal megnézhessük oroszul. A felületen nem találtam ilyen lehetőséget.

Kényelmetlen a diagnosztikai szintekkel a konzolon keresztül dolgozni

Kezdjük azzal, hogy a két parancs használt (ez pvs-studio-analyzer и plog-converter) különböző formátumok a diagnosztika megadásához.

Segítség a pvs-studio-analyzer így szól:

-a [MODE], --analysis-mode [MODE]
    MODE defines the type of warnings:
    1 - 64-bit errors;
    2 - reserved;
    4 - General Analysis;
    8 - Micro-optimizations;
    16 - Customers Specific Requests;
    32 - MISRA.
    Modes can be combined by adding the values
    Default: 4

Sokáig próbáltam kitalálni, merre induljak hozzáad (“értékek hozzáadása”) gombokat. Megpróbáltam vesszővel elválasztva felsorolni őket:

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

Többször próbáltam regisztrálni a kulcsot:

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

És csak akkor jöttem rá, hogy ezek kis maszkok! És neked kell összegezés nem hozzáad jelentések. Például az általános diagnosztikához, a mikrooptimalizálások diagnosztikájához és a MISRA-hoz össze kell foglalnia ezeket (4 + 8 + 32 = 44):

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

A bitmaszkok használata a felhasználói felületeken általában rossz forma. Mindezt belsőleg is össze lehetne foglalni, és a felhasználó számára be lehetne állítani egy jelzőkészletet.

Ezen kívül van még egy segédprogram is plog-converter, amely ember által olvasható statikus elemzési információkat generál. Más problémái vannak.

Segítség a programhoz plog-converter jelentések:

-a, --analyzer            Specifies analyzer(s) and level(s) to be
                          used for filtering, i.e.
                          'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                          Default: GA:1,2

Itt megjelentek olyan „szintek”, amelyek korábban nem voltak, és a dokumentációban sem találtam róluk semmit.

Általában nem világos. Ezért mindent a maximumra állítottam.

Egy csomó hülye káromkodás Catch-re

Az általam elemzett három projekt közül kettő egységtesztelési könyvtárat használ Catch2. És az üzenetek oroszlánrésze (!!! az egyikben 90-ból 138, a másikban 297-ből 344!!!) a következő formájú:

Nem veszi figyelembe a többszálasságot

Sok téves pozitívum van az állítólag változatlan változókkal vagy végtelen ciklusokkal kapcsolatban, miközben ezekkel a változókkal különböző szálakból történik a munka, és ha ez nem így lenne, akkor az egységtesztek nem működnének.

De egy statikus analizátor ezt egyáltalán figyelembe tudja venni? Nem tudom.

Eredményei

A PVS nem talált valódi hibát a nyílt forráskódú projektjeimben Robbanás и Következő, valamint egy munkatervezetben, amit nyilvánvaló okokból nem tudok bemutatni. Igaz, érdemes szem előtt tartani, hogy néhány hiányosságot már a korábbi használat során észleltek és kijavítottak Cppcheck и scan-build.

Általában az összes elemző benyomása megközelítőleg ugyanaz: igen, elkapnak valamit, néha még valami fontosat is, de összességében elég a fordító.

Lehetséges (és én személy szerint szeretem így gondolni), hogy csapatunk olyan szoftverfejlesztési gyakorlatot alkalmaz, amely lehetővé teszi számunkra, hogy minimális mennyiségű szar kódot generáljunk. Jobb nem okozni problémákat, mint hősiesen legyőzni azokat.

Ezért megfogadom a bátorságot, hogy adok néhány tanácsot, hogyan írjunk C++-ban úgy, hogy ne lövik le senkinek a lábát, és ne üssünk homlokon senkit gereblyével.

Hozza ki a legtöbbet a fordítói diagnosztikából

Csapatunk a következő összeállítási lehetőségeket használja (és tanácsolja Önnek):

-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

Engedélyezze őket a projektben, és tudjon meg sokat a kódjáról.

Ragaszkodjon a szabványhoz

Próbáljon meg ne használni platformfüggő dolgokat, ha vannak szabványos analógok, és ha egyáltalán nem nélkülözheti őket, csomagolja be őket speciális makrók blokkjaiba (vagy valami másba), és egyszerűen ne hagyja, hogy a kódot nem támogatott körülmények között fordítsák le.

Ragaszkodjon a szabványos műveleti szemantikához

Az összeadásnak összeadásnak, a szorzásnak szorzásnak kell lennie, a függvényhívásnak függvényhívásnak, a másolásnak másolásnak, a hordozásnak a hordozónak kell lennie, a tárolónak iterálhatónak kell lennie, az iterátornak promócióval kell rendelkeznie ++ és a hivatkozások megszüntetése *. És így tovább, és így tovább.

Szerintem egyértelmű az ötlet. Vannak bevett konvenciók, amelyek nem kötelezőek, de a kód minden felhasználója és olvasója látni fogja őket. Ne próbálj kijátszani másokat, különben saját magadat fogod kijátszani.

Írjon kompatibilis kódot

Először is a standard könyvtárra gondolok. Nagyon kívánatos, hogy az osztályok és függvények interfészei használhatók legyenek a szabványos és más könyvtárakkal (például Boost).

Nyugodtan vessen egy pillantást az STL és a Boost felületekre. Ritka kivételektől eltekintve méltó példaképet fog látni ott.

Hozza ki a legtöbbet a nyílt forráskódú eszközökből

Ugyanazon statikus elemzéshez legalább két nyitott ingyenes eszköz létezik, amelyek csak egyszer csatlakoztathatók bármely projekthez a CMake build rendszerrel.

Erről bővebben a legutóbbi publikációmban olvashat.

utószó

Végül szeretném hangsúlyozni, hogy nem támogatom a PVS vagy más statikus analizátorok használatát. De arra biztatlak, gondold át, hogyan történhetett, hogy a statikus elemző folyamatosan jelentős hibákat talál a kódodban.

Ez csak következmény. Meg kell keresnünk és meg kell szüntetni az okot.

Forrás: will.com