Revisión independente de PVS-Studio (Linux, C++)

Vin unha publicación que PVS aprendera a analizar baixo Linux e decidín probala nos meus propios proxectos. E isto é o que saíu del.

Contido

1. Pros
2. Contra
3. Resultados de
4. Posterior

Pros

Apoio receptivo

Pedín unha chave de proba e enviáronma o mesmo día.

Documentación bastante clara

Conseguimos lanzar o analizador sen problemas. Tamén está dispoñible axuda para os comandos da consola (aínda que aquí hai algunhas queixas, consulte a sección Contra).

Posibilidade de análise multiproceso

O analizador ten unha opción "estándar". -j, permitindo realizar análises paralelamente en varias tarefas. Isto aforra moito tempo.

Boa visualización

Moitos formatos de saída diferentes, desde texto ata un pequeno fociño web. A interface web é cómoda, concisa, con suxestións xunto ás liñas do código e ligazóns a descricións de diagnóstico.

Fácil integración na montaxe

Toda a documentación está no seu sitio web, só podo dicir que se o teu proxecto está construído usando CMake, todo é moi sinxelo.

Boas descricións de diagnóstico

Se xera saída en modo fullhtml, entón cada mensaxe ten unha ligazón a unha descrición de diagnóstico, con explicacións, exemplos de código e ligazóns adicionais.

Contra

Descoñecemento da linguaxe C++ por parte do analizador

Desafortunadamente, PVS ás veces comete erros de sintaxe e xera mensaxes falsas positivas cando o código é completamente correcto.

Por exemplo, hai unha función que devolve 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));
}

Si é a palabra clave auto Pode significar void, para iso é automático. Pero PVS produciu as seguintes mensaxes:

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.

Sitio moi lento

Si, na interface web ao carón de cada mensaxe hai unha ligazón á descrición do diagnóstico correspondente con exemplos. Pero cando fai clic nunha ligazón, ten que esperar moito tempo, e ás veces ocorre 504 Tempo de espera da pasarela.

Linguaxe

Todas as descricións están en ruso, o que é xenial. Pero as ligazóns do informe sempre levan á versión en inglés. Sería bo poder cambiar o idioma para poder ver os diagnósticos inmediatamente en ruso. Non atopei tal opción na interface.

É inconveniente traballar con niveis de diagnóstico a través da consola

Comecemos co feito de que os dous comandos utilizados (este pvs-studio-analyzer и plog-converter) diferentes formatos para especificar diagnósticos.

Axuda para pvs-studio-analyzer le:

-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

Pasei moito tempo intentando descubrir onde ir engadir teclas (“engadir os valores”). Intentei enumeralos separados por comas:

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

Tentei rexistrar a chave varias veces:

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

E só entón decateime de que se trataban de máscaras de pouco! E precisas resumirpero non engadir significados. Por exemplo, para obter diagnósticos xerais, diagnósticos para microoptimizacións e MISRA, cómpre sumalos (4 + 8 + 32 = 44):

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

Usar máscaras de bits nas interfaces de usuario é xeralmente de mala forma. Todo isto podería resumirse internamente e establecer un conxunto de bandeiras para o usuario.

Ademais, tamén hai unha utilidade plog-converter, que xera información de análise estática lexible por humanos. Ela ten outros problemas.

Axuda para o 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,2

Aquí apareceron algúns "niveis" que antes non estaban, e tampouco atopei nada sobre eles na documentación.

En xeral, non está claro. Por iso puxen todo ao máximo.

Unha chea de estúpidos xuros en Catch

Dous dos tres proxectos que analizei usan unha biblioteca de probas unitarias Catch2. E a maior parte das mensaxes (!!! 90 de 138 nunha e 297 de 344 na outra!!!) teñen a seguinte forma:

Non ten en conta o multithreading

Hai moitos falsos positivos sobre variables supostamente invariables ou bucles interminables, mentres que o traballo con estas variables prodúcese desde diferentes fíos, e se isto non fose así, as probas unitarias non funcionarían.

Non obstante, un analizador estático pode ter isto en conta? Non sei.

Resultados de

PVS non atopou ningún erro real nos meus proxectos de código aberto Explosión и A continuación, así como nun borrador de traballo que, por razóns obvias, non podo presentar. É certo, convén ter en conta que algunhas deficiencias xa foron detectadas e corrixidas anteriormente usando Cppcheck и scan-build.

En xeral, a impresión de todos estes analizadores é aproximadamente a mesma: si, captan algo, ás veces incluso algo importante, pero en xeral o compilador é suficiente.

É posible (e a min persoalmente gústame pensar que si) que o noso equipo utilice prácticas de desenvolvemento de software que nos permitan xerar unha cantidade mínima de código de merda. É mellor non crear problemas que superalos heroicamente.

Polo tanto, tómome a liberdade de dar algúns consellos sobre como escribir en C++ de forma que non se lle dispare as pernas a ninguén nin lle pegue a ninguén na fronte cun anciño.

Aproveita ao máximo os diagnósticos do compilador

O noso equipo utiliza (e aconsella) as seguintes opcións de compilación:

-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

Habilitalos no teu proxecto e aprende moito sobre o teu código.

Cómprese co estándar

Tenta non usar cousas dependentes da plataforma se hai análogos estándar, e se non podes prescindir deles, envólveas en bloques especiais para macros (ou outra cousa) e simplemente non deixes que o teu código se compile en condicións non admitidas.

Cómprese na semántica de operación estándar

A suma debe ser suma, a multiplicación debe ser a multiplicación, a chamada de función debe ser chamada a función, a copia debe ser copia, o transporte debe ser transportado, o contenedor debe ser iterable, o iterador debe ter promoción ++ e desreferenciación *. E así por diante.

Creo que a idea está clara. Existen convencións establecidas que non son vinculantes, pero que todos os usuarios e lectores do teu código esperan ver. Non intentes burlar aos demais, se non, superarás a ti mesmo.

Escribir código compatible

En primeiro lugar, refírome á biblioteca estándar. É moi desexable que as interfaces das súas clases e funcións se poidan usar con bibliotecas estándar e outras (por exemplo, Boost).

Non dubides en botar unha ollada ás interfaces STL e Boost. Con raras excepcións, verás un modelo digno a seguir.

Aproveita ao máximo as ferramentas de código aberto

Para a mesma análise estática, hai polo menos dúas ferramentas gratuítas abertas que se poden conectar só unha vez a calquera proxecto co sistema de compilación CMake.

Podes ler máis sobre isto na miña recente publicación.

Posterior

Finalmente, gustaríame subliñar que non estou a defender non usar PVS nin ningún outro analizador estático. Pero anímoche a pensar en como ocorreu que o analizador estático atopa constantemente erros significativos no teu código.

Isto é só unha consecuencia. Hai que buscar e eliminar a causa.

Fonte: www.habr.com