Uavhengig omtale av PVS-Studio (Linux, C++)

Jeg så et innlegg om at PVS endelig har lært seg å analysere under Linux, og bestemte meg for å prøve det ut på prosjektene mine. Her er hva som kom ut av det.

Innhold

1. Fordeler
2. Ulemper
3. Resultater
4. Etterord

Fordeler

Reaktiv støtte

Jeg ba om en prøveversjon, og samme dag fikk jeg den.

Ganske forståelig dokumentasjon

Det var ikke store problemer med å starte analysatoren. Det finnes også hjelp til kommandolinjeverktøyene (selv om det er noen klager, se seksjonen Ulemper).

Muligheten for multitrådet analyse

Analysatoren har et «standard» alternativ -j, som gjør det mulig å analysere parallelt på flere oppgaver. Dette sparer mye tid.

God visualisering

Mange forskjellige utdataformater, fra tekst til en liten nettgrensesnitt. Nettsiden er brukervennlig, kompakt, med hjelpetips ved siden av linjene i koden og lenker til diagnostiske beskrivelser.

Enkel integrasjon i byggprosessen

All dokumentasjon finnes på nettstedet deres, jeg vil bare si at hvis prosjektet ditt bygges med CMake, så er alt veldig enkelt.

Gode beskrivelser av diagnostikkene

Hvis du genererer utdata i modusen fullhtml, vil hver melding ha en lenke til beskrivelsen av diagnosen, med forklaringer, kodeeksempler og flere lenker.

Ulemper

Analysatoren har ikke kunnskap om C++

Dessverre gjør PVS noen ganger syntaksfeil og genererer falske positive meldinger når koden er helt korrekt.

For eksempel er det en funksjon som returnerer 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, nøkkelordet auto kan bety void, nettopp som det skal. auto. Men PVS ga meg disse meldingene:

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.

Veldig treg nettside

Ja, i nettgrensesnittet er det en lenke ved siden av hver melding som peker til den tilsvarende diagnosens beskrivelse med eksempler. Men når du klikker på lenken, må du vente ganske lenge, og noen ganger er det 504 Gateway Time-out.

Språk

Alle beskrivelser er på russisk, det er flott. Men lenkene i rapporten fører alltid til den engelske versjonen. Det ville vært bra å ha muligheten til å bytte språk, slik at jeg kunne se diagnostikkene umiddelbart på russisk. Jeg fant ikke en slik mulighet i grensesnittet.

Det er ukomfortabelt å jobbe med diagnostikk-nivåer via konsollen

La oss begynne med at de to brukte kommandoene (dette er pvs-studio-analyzer og plog-converter) har forskjellige formater for å sette diagnostikk.

Hjelpen til pvs-studio-analyzer sier:

-a [MODE], --analysis-mode [MODE]
    MODE definerer typen varsler:
    1 - 64-bit feil;
    2 - reservert;
    4 - Generell Analyse;
    8 - Mikrooptimaliseringer;
    16 - Kundespesifikke forespørsmål;
    32 - MISRA.
    Moduser kan kombineres ved å legge sammen verdiene
    Standard: 4

Jeg prøvde lenge å forstå hvor jeg skulle legge til («adding the values») nøkler. Jeg prøvde å oppgi dem med komma:

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

Jeg prøvde å skrive nøkkelen flere ganger:

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

Og først etterpå innså jeg at dette er bitmasker! Og jeg må summere, og ikke legge til verdiene. For eksempel, for å få generell diagnostikk, diagnostikk for mikrooptimaliseringer og MISRA, må jeg summere dem (4 + 8 + 32 = 44):

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

Bruken av bitmasker i brukergrensesnitt er som regel dårlig stil. Alt dette kunne vært summert internt, mens brukeren får et sett med flagg.

I tillegg finnes det et verktøy plog-converter, som genererer menneske-leselig informasjon om statisk analyse. Den har andre problemer.

Hjelpen til programmet plog-converter opplyser:

-a, --analyzer             Angir analyzer(e) og nivå(er) som skal
                           brukes for filtrering, dvs.
                           'GA:1,2;64:1;OP:1,2,3;CS:1;MISRA:1,2'
                           Standard: GA:1,2

Her dukker det opp noen «nivåer» som ikke har vært nevnt noe sted tidligere, og jeg fant heller ikke noe om dem i dokumentasjonen.

Generelt sett er det uklart. Derfor satte jeg alt til maks.

Masse meningsløs klaging på Catch

I to av tre prosjekter jeg analyserte, brukes bibliotekt for modulær testing Catch2. Og en stor del av meldingene (!!! 90 av 138 i ett og 297 av 344 i et annet !!!) har følgende form:

Tar ikke hensyn til multitråding

Mange falske positive varsler om angivelig uforanderlige variabler eller uendelige sløyfer, mens det jobbes med disse variablene fra forskjellige tråder, og hvis det ikke hadde vært tilfelle, ville ikke enhetstestene ha utløst.

Men kan en statisk analyserer i det hele tatt ta hensyn til dette? Vet ikke.

Resultater

PVS fant ingen virkelige feil i mine åpne prosjekter Burst og Proxima, samt i et arbeidsprosjekt som jeg, av åpenbare grunner, ikke kan vise frem. Det er imidlertid verdt å merke seg at noen mangler allerede har blitt oppdaget og rettet tidligere med hjelp av Cppcheck og scan-build.

Generelt er inntrykket av alle disse analysatorene omtrent det samme: ja, de oppdager noe, noen ganger til og med noe viktig, men generelt er kompilatoren tilstrekkelig.

Det er mulig (og jeg liker å tenke slik) at vårt team bruker utviklingsmetoder som gjør det mulig å generere et minimum av dårlig kode. Det er bedre å unngå problemer enn å måtte overvinne dem på heroisk vis.

Derfor tar jeg mot til meg å gi noen råd om hvordan man kan skrive i C++ slik at man ikke skyter seg selv i foten og unngår å bli truffet av rake.

Bruk kompilatorens diagnostikk maksimalt

Vårt team bruker (og anbefaler dere) følgende kompilasjonsvalg:

-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 prosjektet ditt, så vil du lære mye nytt om koden din.

Hold deg til standarden

Forsøk å unngå plattformavhengige elementer hvis det finnes standardanalyser, og hvis du absolutt må bruke dem, pakk dem inn i spesielle blokker med makroer (eller på en annen måte) og sørg for at koden din ikke kan kompileres under uforenlige forhold.

Hold deg til standard semantikk for operasjoner

Addisjon bør være addisjon, multiplikasjon bør være multiplikasjon, funksjonskall skal være funksjonskall, kopiering bør kopiere, flytting skal flytte, beholdere må være itererbare, og iteratorer må kunne oppgradere ++ og dereferere *. Og så videre, og så videre.

Jeg tror tanken er forstått. Det finnes etablerte konvensjoner som ikke er obligatoriske, men som alle brukere og lesere av koden din forventer å se. Prøv ikke å overkloke andre, da kan du ende opp med å overkloke deg selv.

Skriv kompatibel kode

Først og fremst tenker jeg på standardbiblioteket. Det er meget ønskelig at grensesnittene til klassene og funksjonene dine kan brukes med standard- og andre biblioteker (for eksempel Boost).

Ikke nøl med å se på grensesnittene i STL og Boost. Med sjeldne unntak finner du der verdige eksempler å etterligne.

Bruk åpne verktøy maksimalt

For the same static analysis, there are at least two open-source free tools that can connect to any project with a CMake build system.

You can read more about this in my recent publication..

Etterord

Finally, I want to emphasize that I am not advocating against using PVS or any other static analyzers. However, I encourage you to think about how it happened that the static analyzer continually finds significant errors in your code.

This is just a consequence. You need to look for and eliminate the cause.

Kilde: habr.com