Vaig veure una publicació que PVS havia après a analitzar amb Linux i vaig decidir provar-la en els meus propis projectes. I això és el que en va sortir.
Contingut
Suport sensible
Vaig demanar una clau de prova i me la van enviar el mateix dia.
Documentació bastant clara
Hem aconseguit posar en marxa l'analitzador sense cap problema. També hi ha disponible ajuda per a les ordres de la consola (tot i que aquí hi ha algunes queixes, vegeu la secció ).
Possibilitat d'anàlisi multifils
L'analitzador té una opció "estàndard". -j, permetent realitzar anàlisis paral·lelament en diverses tasques. Això estalvia molt de temps.
Bona visualització
Molts formats de sortida diferents, des de text fins a un petit morrió web. .
Fàcil integració en el muntatge
Tota la documentació es troba al seu lloc web, només puc dir que si el vostre projecte es construeix amb CMake, aleshores tot és molt senzill.
Bones descripcions de diagnòstic
Si genereu sortida en mode fullhtml, a continuació, cada missatge té un enllaç a una descripció de diagnòstic, amb explicacions, exemples de codi i enllaços addicionals.
Desconeixement del llenguatge C++ per part de l'analitzador
Malauradament, PVS de vegades fa errors de sintaxi i genera missatges falsos positius quan el codi és completament correcte.
Per exemple, hi ha una funció que retorna 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));
}Sí és la paraula clau auto Pot significar void, per això serveix cotxe. Però PVS va produir els missatges següents:
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.Lloc molt lent
Sí, a la interfície web al costat de cada missatge hi ha un enllaç a la descripció de diagnòstic corresponent amb exemples. Però quan feu clic a un enllaç, heu d'esperar bastant temps, i de vegades passa .
Idioma
Totes les descripcions estan en rus, la qual cosa és genial. Però els enllaços de l'informe sempre porten a la versió en anglès. Seria bo poder canviar l'idioma per poder veure els diagnòstics immediatament en rus. No he trobat aquesta opció a la interfície.
És inconvenient treballar amb nivells de diagnòstic a través de la consola
Comencem pel fet que les dues ordres utilitzades (això pvs-studio-analyzer и plog-converter) diferents formats per especificar diagnòstics.
Ajuda per pvs-studio-analyzer llegeix:
-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: 4Vaig passar molt de temps intentant esbrinar on anar afegir tecles (“afegir els valors”). Vaig intentar enumerar-los separats per comes:
pvs-studio-analyzer analyze ... -a 1,4,16He intentat registrar la clau diverses vegades:
pvs-studio-analyzer analyze ... -a 1 -a 4 -a 16I només aleshores em vaig adonar que eren unes màscares! I necessites resumirI no afegir significats. Per exemple, per obtenir diagnòstics generals, diagnòstics per a microoptimitzacions i MISRA, cal que els resumis (4 + 8 + 32 = 44):
pvs-studio-analyzer analyze ... -a 44L'ús de màscares de bits a les interfícies d'usuari és generalment una mala forma. Tot això es podria resumir internament i es podria establir un conjunt de banderes per a l'usuari.
A més, també hi ha una utilitat plog-converter, que genera informació d'anàlisi estàtica llegible pels humans. Té altres problemes.
Ajuda per al programa plog-converter informes:
-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,2Aquí van aparèixer alguns "nivells" que abans no hi eren, i tampoc n'he trobat res a la documentació.
En general, no està clar. Per això ho vaig posar tot al màxim.
Un munt de juraments estúpids a Catch
Dos dels tres projectes que vaig analitzar utilitzen una biblioteca de proves unitàries . I la part del lleó dels missatges (!!! 90 de 138 en un i 297 de 344 en l'altre!!!) tenen la forma següent:
No té en compte el multithreading
Hi ha molts falsos positius sobre variables suposadament immutables o bucles interminables, mentre que el treball amb aquestes variables es produeix des de diferents fils, i si no fos així, les proves unitàries no funcionarien.
Tanmateix, un analitzador estàtic pot tenir-ho en compte? No ho sé.
PVS no va trobar cap error real als meus projectes de codi obert и , així com en un esborrany de treball que, per raons òbvies, no puc presentar. És cert que val la pena tenir en compte que algunes deficiències ja s'han detectat i corregit abans utilitzant и .
En general, la impressió de tots aquests analitzadors és aproximadament la mateixa: sí, capten alguna cosa, de vegades fins i tot alguna cosa important, però en general el compilador és suficient.
És possible (i personalment m'agrada pensar que sí) que el nostre equip utilitzi pràctiques de desenvolupament de programari que ens permetin generar una quantitat mínima de codi de merda. És millor no crear problemes que superar-los heroicament.
Per tant, em prenc la llibertat de donar alguns consells sobre com escriure en C++ de manera que no es dispari les cames de ningú ni es pegui al front amb un rasclet.
Aprofiteu al màxim els diagnòstics del compilador
El nostre equip utilitza (i us aconsella) les opcions de compilació següents:
-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-promoActiveu-los al vostre projecte i apreneu molt sobre el vostre codi.
Seguiu l'estàndard
Intenteu no utilitzar coses que depenen de la plataforma si hi ha anàlegs estàndard i, si no podeu prescindir d'ells, embolcalleu-los en blocs especials per a macros (o una altra cosa) i simplement no deixeu que el vostre codi es compile en condicions no compatibles.
Seguiu la semàntica d'operació estàndard
La suma ha de ser una suma, la multiplicació ha de ser una multiplicació, la trucada de funció ha de ser una trucada de funció, la còpia ha de ser una còpia, la càrrega ha de ser transportada, el contenidor ha de ser iterable, l'iterador ha de tenir promoció ++ i desreferenciació *. I així successivament i així successivament.
Crec que la idea és clara. Hi ha convencions establertes que no són vinculants, però que tots els usuaris i lectors del vostre codi esperen veure. No intenteu burlar els altres, sinó us burlaràs a tu mateix.
Escriu codi compatible
En primer lloc, em refereixo a la biblioteca estàndard. És molt desitjable que les interfícies de les vostres classes i funcions es puguin utilitzar amb biblioteques estàndard i altres (per exemple, Boost).
No dubteu a fer una ullada a les interfícies STL i Boost. Amb rares excepcions, hi veureu un model digne.
Aprofiteu al màxim les eines de codi obert
Per a la mateixa anàlisi estàtica, hi ha almenys dues eines gratuïtes obertes que es poden connectar només una vegada a qualsevol projecte amb el sistema de compilació CMake.
.
Finalment, m'agradaria subratllar que no estic advocant per no utilitzar PVS ni cap altre analitzador estàtic. Però us animo a pensar com va passar que l'analitzador estàtic troba constantment errors significatius al vostre codi.
Això és només una conseqüència. Hem de buscar i eliminar la causa.
Font: www.habr.com