Oberoende granskning av PVS-Studio (Linux, C++)

Jag såg ett inlägg om att PVS faktiskt har lärt sig att analysera under Linux, och jag bestämde mig för att prova på mina projekt. Och så här blev resultatet.

Innehåll

1. Fördelar
2. Nackdelar
3. Sammanfattning
4. Epilog

Fördelar

Responsiv support

Jag begärde en provnyckel, och samma dag fick jag den.

Tillräckligt tydlig dokumentation

Analysatorn kunde startas utan större problem. Det finns också hjälp för kommandoradsalternativ (även om det finns vissa klagomål, se avsnittet Nackdelar).

Möjlighet till flertrådad analys

Analysatorn har ett "standard" alternativ -j, vilket möjliggör analys parallellt i flera uppgifter. Detta sparar mycket tid.

Bra visualisering

Många olika utdataformat, från text till en liten webbgränssnitt. Webbgränssnittet är användarvänligt, minimalistiskt, med tips intill raderna i koden och länkar till beskrivningar av diagnostik..

Enkel integration i bygget

All dokumentation finns på deras webbplats. Jag kan bara säga att om ditt projekt byggs med hjälp av CMake är det väldigt enkelt.

Bra beskrivningar av diagnostik

Om du genererar utdata i läget fullhtml, så har varje meddelande en länk till beskrivningen av diagnostiken, med förklaringar, kodexempel och ytterligare länkar.

Nackdelar

Okunskap hos analysatorn om C++-språket

Tyvärr gör PVS ibland syntaktiska fel och genererar falska positiva meddelanden för helt korrekt kod.

Till exempel, det finns en funktion som returnerar 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));
}

Ja, nyckelordet auto kan betyda void, så är det auto. Men PVS gav följande meddelanden:

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.

Mycket seg webbplats

Ja, i webbgränssnittet finns det en länk vid varje meddelande som går till motsvarande beskrivning av diagnostik med exempel. Men vid klick på länken får man vänta ganska länge, och ibland händer det att det är 504 Gateway Time-out.

Språk

Alla beskrivningar finns på ryska, vilket är bra. Men länkarna i rapporten leder alltid till den engelska versionen. Det vore bra att ha möjlighet att växla språk så att man kan se diagnostiken direkt på ryska. Jag har inte hittat en sådan möjlighet i gränssnittet.

Det är besvärligt att arbeta med diagnosnivåer genom konsolen

Låt oss börja med att de två använda kommandona (detta pvs-studio-analyzer och plog-converter) har olika format för diagnostik.

Hänvisning till pvs-studio-analyzer anger:

-a [MODE], --analysis-mode [MODE]
    MODE definierar typen av varningar:
    1 - 64-bitarsfel;
    2 - reserverad;
    4 - Allmän analys;
    8 - Mikrooptimeringar;
    16 - Specifika kundförfrågningar;
    32 - MISRA.
    Lägen kan kombineras genom att lägga till värdena
    Standard: 4

Jag försökte länge förstå var jag behövde lägga till ('adding the values') nycklar. Jag försökte lista separerat med kommatecken:

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

Jag försökte ange nyckeln flera gånger:

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

Och först då insåg jag att det var bitmasker! Och jag behövde summera, inte lägga till värdena. Till exempel, för att få allmänna diagnostik, diagnostik för mikrooptimeringar och MISRA, behövde jag summera dem (4 + 8 + 32 = 44):

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

Att använda bitmasker i användargränssnitt är som regel dålig stil. Allt detta kunde summeras internt, och användaren kunde få ett uppsättning flaggor.

Dessutom finns det en annan verktyg plog-converter, som genererar mänskligt läsbar information om statisk analys. Den har andra egenheter.

Hänvisning till programmet plog-converter anger:

-a, --analyzer            Anger analysator(er) och nivå(er) som ska
                          användas för filtrering, dvs.
                          'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                          Standard: GA:1,2

Här har det dykt upp några "nivåer" som tidigare inte funnits någonstans, och jag hittade inget i dokumentationen om dem heller.

Det är överlag oklart. Därför satte jag allt på max.

Mycket meningslös kritik på Catch

I två av tre projekt som jag analyserade används testbiblioteket Catch2. Och en stor del av meddelandena (!!! 90 av 138 i det ena och 297 av 344 i det andra !!!) ser ut så här:

Tar inte hänsyn till flertrådighet

Många falska positiva träffar om påstått oföränderliga variabler eller oändliga loopar, medan arbetet med dessa variabler sker från olika trådar, och om det inte vore så skulle enhetstesterna inte triggas.

Frågan är om en statisk analysator kan beakta detta? Jag vet inte.

Sammanfattning

PVS hittade inga verkliga fel i mina öppna projekt Burst och Proxima, samt i ett arbetsprojekt som jag av uppenbara skäl inte kan presentera. Det är dock värt att notera att vissa brister redan hade fångats och åtgärdats tidigare med hjälp av Cppcheck och scan-build.

Sammanfattningsvis är intrycket av alla dessa analysatorer i stort sett detsamma: ja, de fångar något, ibland till och med något viktigt, men i stort sett räcker en kompilator.

Kanske (och personligen är jag glad att tänka så) använder vårt team utvecklingspraxis som gör att vi genererar minimiantal skämtkod. Bättre att inte skapa problem än att heroiskt övervinna dem.

Så jag vågar ge några råd om hur man skriver i C++ utan att skjuta sig själv i foten och undvika att slå sig i pannan med krattor.

Använd kompilatordiagnoser maximalt

Vårt team använder (och rekommenderar er) följande kompilationsalternativ:

-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

Inkludera dem i ert projekt, så lär ni er mycket nytt om er kod.

Håll er till standarden

Försök att inte använda plattformsberoende saker om det finns standardalternativ, och om ni inte kan undvika dem helt, svep in dem i speciella block under makron (eller på något annat sätt) och se till att er kod inte kan kompileras i oförutsedda förhållanden.

Håll er till standardsemantiken för operationer

Addition ska vara addition, multiplikation ska vara multiplikation, funktionsanrop ska vara funktionsanrop, kopiering ska kopiera, flytt ska flytta, containern ska vara itererbar, iteratorn ska ha förflyttning ++ och avreferering. *. Och så vidare, och så vidare.

Jag tror att poängen är förstådd. Det finns etablerade konventioner som inte är obligatoriska att följa, men som alla användare och läsare av er kod förväntar sig att se. Försök inte att överlista andra, för då kommer ni att överlista er själva.

Skriv kompatibel kod

Först och främst menar jag standardbiblioteket. Det är mycket önskvärt att gränssnitten för era klasser och funktioner kan användas med standard- och andra bibliotek (till exempel Boost).

Tveka inte att titta på gränssnitten i STL och Boost. Med sällsynta undantag kommer ni där att se värdiga exempel att efterlikna.

Använd öppna verktyg maximalt

För samma statiska analys finns det minst två öppna gratisverktyg som kopplar upp sig mot vilket projekt som helst med CMake-byggsystemet.

Mer om detta kan läsas i min senaste publikation..

Epilog

Till sist vill jag understryka att jag inte uppmanar till att inte använda PVS eller några andra statiska analyssystem. Men jag uppmanar till att tänka på hur det kan ha hänt att den statiska analysatorn ständigt hittar betydande fel i din kod.

Detta är bara en följd. Man måste söka efter och åtgärda orsaken.

Källa: habr.com