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

Jag såg en publikation som PVS hade lärt sig att analysera under Linux och bestämde mig för att prova den på mina egna projekt. Och det här är vad som kom ut ur det.


Innehåll

  1. Fördelar
  2. Nackdelar
  3. Resultat av
  4. efterordet

Fördelar

Responsiv support

Jag begärde en testnyckel och de skickade den till mig samma dag.

Ganska tydlig dokumentation

Vi lyckades starta analysatorn utan problem. Hjälp för konsolkommandon är också tillgänglig (även om det finns några klagomål här, se avsnittet Nackdelar).

Möjlighet till flertrådig analys

Analysatorn har ett "standard"-alternativ -j, vilket gör att analyser kan utföras parallellt i flera uppgifter. Detta sparar mycket tid.

Bra visualisering

Många olika utdataformat, från text till ett litet nätmunkorg. Webbgränssnittet är bekvämt, kortfattat, med tips bredvid rader i koden och länkar till diagnostiska beskrivningar.

Enkel integration i monteringen

All dokumentation finns på deras hemsida, jag kan bara säga att om ditt projekt är byggt med CMake så är allt väldigt enkelt.

Bra diagnostiska beskrivningar

Om du genererar utdata i läge fullhtml, då har varje meddelande en länk till en diagnostisk beskrivning, med förklaringar, kodexempel och ytterligare länkar.

Nackdelar

Analysatorns okunskap om C++-språket

Tyvärr gör PVS ibland syntaxfel och genererar falska positiva meddelanden när koden är helt korrekt.

Det finns till exempel 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, nyckelord auto Kan betyda void, det är vad det är till för bil. Men PVS producerade 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 långsam sida

Ja, i webbgränssnittet bredvid varje meddelande finns en länk till motsvarande diagnostiska beskrivning med exempel. Men när man klickar på en länk får man vänta ganska länge, och ibland händer det 504 Gateway Time-out.

språk

Alla beskrivningar är på ryska, vilket är bra. Men länkar från rapporten leder alltid till den engelska versionen. Det skulle vara trevligt att kunna byta språk så att du kan se diagnostik direkt på ryska. Jag hittade inte ett sådant alternativ i gränssnittet.

Det är obekvämt att arbeta med diagnostiska nivåer via konsolen

Låt oss börja med det faktum att de två kommandona som används (detta pvs-studio-analyzer и plog-converter) olika format för att specificera diagnostik.

Hjälp för pvs-studio-analyzer lyder:

-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

Jag tillbringade lång tid med att försöka komma på vart jag skulle gå lägga till (“att lägga till värdena”) nycklar. Jag försökte lista dem separerade med kommatecken:

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

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

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

Och först då insåg jag att det här var bitmasker! Och du behöver summeraOch inte lägga till betydelser. Till exempel, för att få allmän diagnostik, diagnostik för mikrooptimeringar och MISRA, måste du summera dem (4 + 8 + 32 = 44):

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

Att använda bitmasker i användargränssnitt är i allmänhet dålig form. Allt detta kan sammanfattas internt och en uppsättning flaggor kan ställas in för användaren.

Dessutom finns det också ett verktyg plog-converter, som genererar statisk analysinformation som kan läsas av människor. Hon har andra problem.

Hjälp till programmet plog-converter rapporterar:

-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

Några "nivåer" dök upp här som inte fanns där tidigare, och jag hittade inget om dem i dokumentationen heller.

I allmänhet är det inte klart. Därför satte jag allt till max.

Ett gäng dumma svordomar på Catch

Två av de tre projekt jag analyserade använder ett enhetstestningsbibliotek Catch2. Och lejonparten av meddelanden (!!! 90 av 138 i det ena och 297 av 344 i det andra!!!) har följande form:

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

Tar inte hänsyn till multithreading

Det finns många falska positiva resultat om förmodat oföränderliga variabler eller ändlösa loopar, medan arbete med dessa variabler sker från olika trådar, och om det inte vore så skulle enhetstester inte fungera.

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

Men kan en statisk analysator ens ta hänsyn till detta? Vet inte.

Resultat av

PVS hittade inga riktiga buggar i mina projekt med öppen källkod Brista и Nästa, samt i ett arbetsutkast, som jag av naturliga skäl inte kan lägga fram. Det är sant att det är värt att komma ihåg att vissa brister redan har fångats och korrigerats tidigare Cppcheck и scan-build.

I allmänhet är intrycket från alla dessa analysatorer ungefär detsamma: ja, de fångar något, ibland till och med något viktigt, men totalt sett räcker kompilatorn.

Det är möjligt (och jag personligen gillar att tro det) att vårt team använder metoder för mjukvaruutveckling som tillåter oss att generera en minimal mängd taskig kod. Det är bättre att inte skapa problem än att heroiskt övervinna dem.

Därför tar jag mig friheten att ge några råd om hur man skriver i C++ på ett sådant sätt att man inte skjuter någons ben eller slår någon i pannan med en kratta.

Få ut det mesta av kompilatordiagnostik

Vårt team använder (och råder dig att) följande sammanställningsalternativ:

-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

Aktivera dem i ditt projekt och lär dig mycket om din kod.

Håll dig till standarden

Försök att inte använda plattformsberoende saker om det finns standardanaloger, och om du absolut inte klarar dig utan dem, linda in dem i speciella block för makron (eller något annat) och låt helt enkelt inte din kod kompileras under förhållanden som inte stöds.

Håll dig till standardoperationssemantik

Addition måste vara addition, multiplikation måste vara multiplikation, funktionsanrop måste vara funktionsanrop, kopia måste vara copy, carry måste vara carry, container måste vara iterabel, iterator måste ha marknadsföring ++ och därifrån *. Och så vidare.

Jag tror att tanken är klar. Det finns etablerade konventioner som inte är bindande, men som alla användare och läsare av din kod förväntar sig att se. Försök inte överlista andra, annars kommer du att överlista dig själv.

Skriv kompatibel kod

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

Ta gärna en titt på STL- och Boost-gränssnitten. Med sällsynta undantag kommer du att se en värdig förebild där.

Få ut det mesta av verktyg med öppen källkod

För samma statiska analys finns det minst två öppna gratisverktyg som bara kan kopplas en gång till vilket projekt som helst med CMake-byggsystemet.

Du kan läsa mer om detta i min senaste publikation.

efterordet

Slutligen vill jag betona att jag inte förespråkar att inte använda PVS eller någon annan statisk analysator. Men jag uppmuntrar dig att tänka på hur det gick till att den statiska analysatorn hela tiden hittar betydande fel i din kod.

Detta är bara en konsekvens. Vi måste leta efter och eliminera orsaken.

Källa: will.com

Lägg en kommentar