Uafhængig gennemgang af PVS-Studio (Linux, C++)

Jeg så en post om, at PVS endelig har lært at analysere på Linux, og besluttede at prøve det på mine projekter. Og her er hvad der kom ud af det.

Indhold

1. Fordele
2. Ulemper
3. Resumé
4. Efterord

Fordele

Responsiv support

Jeg anmodede om en prøve-nøgle, og samme dag sendte de den til mig.

Ret klar dokumentation

Det lykkedes at starte analysatoren uden større problemer. Der er også hjælp til konsolkommandoerne (selvom der er nogle kritikpunkter, se afsnit Ulemper).

Mulighed for flertrådet analyse

Analysatoren har en "standard" mulighed -j, der gør det muligt at udføre analysen parallelt i flere opgaver. Det sparer meget tid.

God visualisering

Mange forskellige outputformater, fra tekst til en lille webgrænseflade. Webgrænsefladen er praktisk, minimalistisk, med hints ved siden af kodelinjerne og links til beskrivelser af diagnoser..

Nem integration i byggeprocessen

Al dokumentation er tilgængelig på deres hjemmeside; jeg vil kun sige, at hvis dit projekt bygges med CMake, er det meget enkelt.

Gode beskrivelser af diagnoser

Hvis man genererer output i tilstand fullhtml, så er der et link til beskrivelsen af hver diagnose, med forklaringer, kodeeksempler og yderligere links.

Ulemper

Manglende kendskab til C++

Desværre laver PVS nogle gange syntaksfejl og genererer falsk positive meldinger ved helt korrekt kode.

For eksempel er der en funktion, der returnerer void:

template 
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, nøgleordet auto kan betyde void, som det skal auto. Men PVS gav disse beskeder:

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.

Meget langsom hjemmeside

Ja, i webgrænsefladen er der et link til den relevante diagnoses beskrivelse med eksempler ved siden af hver meddelelse. Men når man klikker på linket, må man vente temmelig længe, og nogle gange får man endda en 504 Gateway Time-out.

Sprog

Alle beskrivelser er tilgængelige på russisk, hvilket er fremragende. Men links fra rapporten fører altid til den engelske version. Det ville være godt at have mulighed for at skifte sprog, så diagnoserne kunne ses med det samme på russisk. Jeg fandt ikke en sådan mulighed i grænsefladen.

Det er besværligt at arbejde med diagnose niveauer gennem konsolen

Lad os starte med, at de to anvendte kommandoer (dette pvs-studio-analyzer og plog-converter) har forskellige formater til at angive diagnosticeringer.

Hjælp til pvs-studio-analyzer siger:

-a [MODE], --analysis-mode [MODE]
    MODE definerer typen af advarsler:
    1 - 64-bit fejl;
    2 - reserveret;
    4 - Generel analyse;
    8 - Mikrooptimeringer;
    16 - Kunder specifikke anmodninger;
    32 - MISRA.
    Modus kan kombineres ved at lægge værdierne sammen.
    Standard: 4

Jeg har længe forsøgt at forstå, hvor jeg skulle tilføje ('adding the values') nøglerne. Jeg prøvede at angive dem med komma:

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

Jeg forsøgte at skrive nøgleordet flere gange:

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

Og først derefter indså jeg, at det faktisk er bitmasker! Og man skal sammenlægge, ikke tilføje værdierne. For eksempel, for at få de generelle diagnosticeringer, diagnosticeringer for mikrooptimeringer og MISRA, skal de sammenlægges (4 + 8 + 32 = 44):

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

Brugen af bitmasker i brugergrænseflader er generelt en dårlig ide. Alt dette kunne være blevet sammenlagt internt, og brugeren kunne have fået en sætning af flag.

Desuden er der et værktøj plog-converter, der genererer læsbar information om statisk analyse. Det har andre finurligheder.

Hjælp til programmet plog-converter oplyser:

-a, --analyzer            Specificerer analyzer(e) og niveau(er), der skal
                          bruges til filtrering, dvs.
                          'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                          Standard: GA:1,2

Her dukkede der nogle 'niveauer' op, som der tidligere ikke var nogen steder, og jeg fandt heller ikke noget i dokumentationen om dem.

Alt i alt er det uklart. Derfor satte jeg altid maks.

En masse meningsløs klager om Catch

I to ud af tre projekter, jeg har analyseret, bruges testbiblioteket Catch2. Og størstedelen af beskederne (!!! 90 ud af 138 i det ene og 297 ud af 344 i det andet !!!) har følgende form:

Overvejer ikke multitrådning

Mange falske positive udløser om angiveligt uforanderlige variable eller uendelige sløjfer, mens der arbejdes med disse variable fra forskellige tråde, og hvis det ikke var tilfældet, ville enheds-testene ikke aktivere.

Men kan en statisk analyser virkelig tage højde for dette? Jeg ved det ikke.

Resumé

PVS fandt ingen rigtige fejl i mine åbne projekter Burst og Proxima, samt i et arbejdsprojekt, som jeg af åbenlyse grunde ikke kan præsentere. Dog skal det bemærkes, at nogle mangler allerede var blevet fanget og rettet tidligere med hjælp fra Cppcheck og scan-build.

Generelt er indtrykket af alle disse analysatorer stort set det samme: ja, de fanger noget, nogle gange endda noget vigtigt, men generelt er kompilatoren tilstrækkelig.

Det er muligt (og personligt er jeg glad for at tænke sådan), at vores team bruger udviklingsmetoder, der genererer minimalt med dårligt kode. Det er bedre ikke at skabe problemer end at skulle overvinde dem heroisk.

Derfor tager jeg mig friheden til at give nogle råd om, hvordan man skriver i C++ for ikke at skyde sig selv i foden eller få en rigtige på panden.

Udnyt kompilatorens diagnostik maksimalt

Vores team bruger (og anbefaler til jer) følgende kompilationsmuligheder:

-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

Inkluder dem i dit projekt, så vil du lære meget nyt om din kode.

Hold dig til standarden

Forsøg at undgå platformafhængige ting, hvis der findes standardalternativer, og hvis du absolut ikke kan undgå dem, pak dem ind i særlige blokke med makroer (eller på anden måde) og sørg for, at din kode ikke kan kompileres under ikke-understøttede forhold.

Hold dig til standardsemantikken for operationer

Addition skal være addition, multiplikation skal være multiplikation, funktionsopkald skal være funktionsopkald, kopiering skal kopiere, flytning skal flytte, en container skal være itererbar, og en iterator skal have fremdrift ++ og dereferering. *Og så videre, og så videre.

Jeg tror budskabet er klart. Der er etablerede konventioner, som ikke er obligatoriske at følge, men som alle brugere og læsere af din kode forventer at se. Forsøg ikke at overlist andre, eller du ender med at overliste dig selv.

Skriv kompatibel kode

Primært mener jeg den standardbibliotek. Det er meget ønskeligt, at dine klassers og funktioners grænseflader kan bruges sammen med standard- og andre biblioteker (f.eks. Boost).

Vær ikke tilbageholdende med at kigge i grænsefladerne for STL og Boost. Med få undtagelser vil du se værdige eksempler at efterligne.

Brug åbne værktøjer maksimalt

Til den samme statiske analyse findes der mindst to åbne gratis værktøjer, der kan tilsluttes ethvert projekt med et CMake-bygget system.

Du kan læse mere om dette i mit nylige indlæg..

Efterord

Til slut vil jeg understrege, at jeg ikke opfordrer til ikke at bruge PVS eller andre statiske analysatorer. Men jeg opfordrer til at overveje, hvordan det kan være, at den statiske analysator konstant finder betydelige fejl i din kode.

Det er blot en konsekvens. Man skal finde og eliminere årsagen.

Kilde: habr.com