Документация по анализатору кода PVS-Studio (одним файлом)

Вы можете открыть всю документацию по PVS-Studio одним файлом, а также "распечатать" ее на виртуальном принтере в .pdf.

Введение

Проверка проектов

На Windows

На Linux и macOS

Регулярное использование в процессе разработки

Развёртывание анализатора в облачных CI

Работа с результатами анализа

Дополнительная настройка и решение проблем

Описание диагностируемых ошибок

  • Сообщения PVS-Studio.
    • Диагностики общего назначения (General Analysis, С++)
    • Диагностики общего назначения (General Analysis, С#)
    • Диагностики общего назначения (General Analysis, Java)
    • Диагностика микро-оптимизаций (С++)
    • Диагностика 64-битных ошибок (С++)
    • Реализовано по запросам пользователей (С++)
    • Проблемы при работе анализатора кода

Дополнительная информация

Сообщения PVS-Studio

Какие ошибки ловит PVS-Studio?

Мы постарались сгруппировать большинство диагностик в несколько групп, чтобы вы могли получить общее представление о возможностях анализатора кода PVS-Studio.

Так как деление диагностик весьма условно, то некоторые диагностики входят в несколько групп. Например, неправильное условие "if (abc == abc)", можно одновременно интерпретировать и как простую опечатку, и как проблему безопасности, так как ошибка приводит к уязвимости кода при некорректных входных данных.

Некоторым ошибкам наоборот места в таблице не нашлось - уж слишком они специфичны. Тем не менее, таблица в целом дает представление о функциональности статического анализатора кода.

Список всех диагностик анализатора в XML

Список диагностик анализатора в формате XML, предназначенный для автоматического разбора, доступен по постоянной ссылке здесь.

Основные диагностические возможности PVS-Studio

Диагностики

64-битные ошибки

C, C++: V101-V128, V201-V207, V220, V221, V301-V303

Адрес локальной переменной возвращается из функции по ссылке

C, C++: V506, V507, V558, V758

Арифметическое переполнение, потеря значимости

C, C++: V636, V658, V784, V786, V1012, V1028, V1029, V1033

C#: V3040, V3041

Java: V6011, V6088

Выход за границу массива

C, C++: V557, V582, V643, V781, V1038

C#: V3106

Java: V6025, V6079

Двойное освобождение ресурсов

C, C++: V586, V749, V1002, V1006

Мёртвый код

C, C++: V606, V607

Микрооптимизации

C, C++: V801-V829

Недостижимый код

C, C++: V551, V695, V734, V776, V779, V785

C#: V3136, V3142

Java: V6018, V6019

Неинициализированные переменные

C, C++: V573, V614, V679, V730, V737, V788, V1007, V1050

C#: V3070, V3128

Java: V6036, V6050, V6052, V6090

Неиспользуемые переменные

C, C++: V603, V751, V763, V1001

C#: V3061, V3065, V3077, V3117, V3137, V3143

Java: V6021, V6022, V6023

Некорректные операции сдвига

C, C++: V610, V629, V673, V684, V770

C#: V3134

Java: V6034, V6069

Неопределенное/неуточняемое поведение

C, C++: V567, V610, V611, V681, V704, V708, V726, V736, V1016, V1026, V1032, V1061

Неправильная работа с типами (HRESULT, BSTR, BOOL, VARIANT_BOOL, float, double)

C, C++: V543, V544, V545, V716, V721, V724, V745, V750, V676, V767, V768, V772, V775, V1027, V1034, V1046, V1060

C#: V3111, V3121, V3148

Неправильное представление о работе функции/класса

C, C++: V518, V530, V540, V541, V554, V575, V597, V598, V618, V630, V632, V663, V668, V698, V701, V702, V717, V718, V720, V723, V725, V727, V738, V742, V743, V748, V762, V764, V780, V789, V797, V1014, V1024, V1031, V1035, V1045, V1052, V1053, V1054, V1057

C#: V3010, V3057, V3068, V3072, V3073, V3074, V3082, V3084, V3094, V3096, V3097, V3102, V3103, V3104, V3108, V3114, V3115, V3118, V3123, V3126, V3145

Java: V6009, V6010, V6016, V6026, V6029, V6049, V6055, V6058, V6064, V6068, V6081

Опечатки

C, C++: V501, V503, V504, V508, V511, V516, V519, V520, V521, V525, V527, V528, V529, V532, V533, V534, V535, V536, V537, V539, V546, V549, V552, V556, V559, V560, V561, V564, V568, V570, V571, V575, V577, V578, V584, V587, V588, V589, V590, V592, V600, V602, V604, V606, V607, V616, V617, V620, V621, V622, V625, V626, V627, V633, V637, V638, V639, V644, V646, V650, V651, V653, V654, V655, V660, V661, V662, V666, V669, V671, V672, V678, V682, V683, V693, V715, V722, V735, V747, V754, V756, V765, V767, V787, V791, V792, V796, V1013, V1015, V1021, V1040, V1051

C#: V3001, V3003, V3005, V3007, V3008, V3009, V3011, V3012, V3014, V3015, V3016, V3020, V3028, V3029, V3034, V3035, V3036, V3037, V3038, V3050, V3055, V3056, V3057, V3062, V3063, V3066, V3081, V3086, V3091, V3092, V3107, V3109, V3110, V3112, V3113, V3116, V3122, V3124, V3132, V3140

Java: V6001, V6005, V6009, V6012, V6014, V6015, V6017, V6021, V6026, V6028, V6029, V6030, V6031, V6037, V6041, V6042, V6043, V6045, V6057, V6059, V6061, V6062, V6063, V6077, V6080, V6085, V6091

Отсутствие виртуального деструктора

C, C++: V599, V689

Оформление кода не совпадает с логикой его работы

C, C++: V563, V612, V628, V640, V646, V705, V1044

C#: V3018, V3033, V3043, V3067, V3069, V3138, V3150

Java: V6040, V6047, V6086, V6089

Ошибки из-за Copy-Paste

C, C++: V501, V517, V519, V523, V524, V571, V581, V649, V656, V691, V760, V766, V778, V1037

C#: V3001, V3003, V3004, V3008, V3012, V3013, V3021, V3030, V3058, V3127, V3139, V3140

Java: V6003, V6004, V6012, V6021, V6027, V6032, V6033, V6039, V6067, V6072

Ошибки при работе с исключениями

C, C++: V509, V565, V596, V667, V740, V741, V746, V759, V1022

C#: V3006, V3052, V3100, V3141

Java: V6006, V6051

Переполнение буфера

C, C++: V512, V514, V594, V635, V641, V645, V752, V755

Проблемы безопасности

C, C++: V505, V510, V511, V512, V518, V531, V541, V547, V559, V560, V569, V570, V575, V576, V579, V583, V597, V598, V618, V623, V642, V645, V675, V676, V724, V727, V729, V733, V743, V745, V750, V771, V774, V782, V1003, V1005, V1010, V1017

C#: V3022, V3023, V3025, V3027, V3053, V3063

Java: V6007, V6046, V6054

Путаница с приоритетом операций

C, C++: V502, V562, V593, V634, V648

C#: V3130, V3133

Java: V6044

Разыменование нулевого указателя/нулевой ссылки

C, C++: V522, V595, V664, V757, V769

C#: V3019, V3042, V3080, V3095, V3105, V3125, V3141, V3145, V3146, V3148, V3149, V3153

Java: V6008, V6060

Разыменование параметров без предварительной проверки

C, C++: V595, V664, V783, V1004

C#: V3095

Java: V6060

Ошибки синхронизации

C, C++: V712, V1011, V1018, V1025, V1036

C#: V3032, V3054, V3079, V3083, V3089, V3090, V3147

Java: V6070, V6074, V6082

Ошибки при использовании WPF

C#: V3044-V3049

Утечки ресурсов

C, C++: V701, V773, V1020, V1023

Целочисленное деление на 0

C, C++: V609

C#: V3064, V3151, V3152

Java: V6020

Ошибки сериализации / десериализации

C, C++: V739, V1024

C#: V3094, V3096, V3097, V3099, V3103, V3104

Java: V6065, V6075, V6076, V6083, V6087

Диагностики, созданные по специальным просьбам пользователей

C, C++: V2001-V2014

Таблица 1 – Возможности PVS-Studio.

Как видите, анализатор максимально проявляет себя в таких областях, как поиск ошибок, возникших из-за опечаток и Copy-Paste. Хорошо диагностирует проблемы, которые связаны с безопасностью кода.

Как всё это работает на практике можно узнать, заглянув в базу ошибок. Мы собираем в эту базу все ошибки, которые нашли, проверяя различные открытые проекты с помощью PVS-Studio.

Диагностики общего назначения (General Analysis, C++)

  • V501. There are identical sub-expressions to the left and to the right of the 'foo' operator.
  • V502. Perhaps the '?:' operator works in a different way than it was expected. The '?:' operator has a lower priority than the 'foo' operator.
  • V503. This is a nonsensical comparison: pointer < 0.
  • V504. It is highly probable that the semicolon ';' is missing after 'return' keyword.
  • V505. The 'alloca' function is used inside the loop. This can quickly overflow stack.
  • V506. Pointer to local variable 'X' is stored outside the scope of this variable. Such a pointer will become invalid.
  • V507. Pointer to local array 'X' is stored outside the scope of this array. Such a pointer will become invalid.
  • V508. The use of 'new type(n)' pattern was detected. Probably meant: 'new type[n]'.
  • V509. Exceptions that were raised inside noexcept functions must be wrapped in a try..catch block.
  • V510. The 'Foo' function is not expected to receive class-type variable as 'N' actual argument.
  • V511. The sizeof() operator returns size of the pointer, and not of the array, in given expression.
  • V512. A call of the 'Foo' function will lead to a buffer overflow or underflow.
  • V513. Use _beginthreadex/_endthreadex functions instead of CreateThread/ExitThread functions.
  • V514. Dividing sizeof a pointer by another value. There is a probability of logical error presence.
  • V515. The 'delete' operator is applied to non-pointer.
  • V516. Consider inspecting an odd expression. Non-null function pointer is compared to null.
  • V517. The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence.
  • V518. The 'malloc' function allocates strange amount of memory calculated by 'strlen(expr)'. Perhaps the correct variant is strlen(expr) + 1.
  • V519. The 'x' variable is assigned values twice successively. Perhaps this is a mistake.
  • V520. The comma operator ',' in array index expression.
  • V521. Such expressions using the ',' operator are dangerous. Make sure the expression is correct.
  • V522. Dereferencing of the null pointer might take place.
  • V523. The 'then' statement is equivalent to the 'else' statement.
  • V524. It is odd that the body of 'Foo_1' function is fully equivalent to the body of 'Foo_2' function.
  • V525. The code contains the collection of similar blocks. Check items X, Y, Z, ... in lines N1, N2, N3, ...
  • V526. The 'strcmp' function returns 0 if corresponding strings are equal. Consider examining the condition for mistakes.
  • V527. It is odd that the 'zero' value is assigned to pointer. Probably meant: *ptr = zero.
  • V528. It is odd that pointer is compared with the 'zero' value. Probably meant: *ptr != zero.
  • V529. Odd semicolon ';' after 'if/for/while' operator.
  • V530. The return value of function 'Foo' is required to be utilized.
  • V531. It is odd that a sizeof() operator is multiplied by sizeof().
  • V532. Consider inspecting the statement of '*pointer++' pattern. Probably meant: '(*pointer)++'.
  • V533. It is likely that a wrong variable is being incremented inside the 'for' operator. Consider reviewing 'X'.
  • V534. It is likely that a wrong variable is being compared inside the 'for' operator. Consider reviewing 'X'.
  • V535. The variable 'X' is being used for this loop and for the outer loop.
  • V536. Be advised that the utilized constant value is represented by an octal form.
  • V537. Consider reviewing the correctness of 'X' item's usage.
  • V538. The line contains control character 0x0B (vertical tabulation).
  • V539. Consider inspecting iterators which are being passed as arguments to function 'Foo'.
  • V540. Member 'x' should point to string terminated by two 0 characters.
  • V541. It is dangerous to print a string into itself.
  • V542. Consider inspecting an odd type cast: 'Type1' to ' Type2'.
  • V543. It is odd that value 'X' is assigned to the variable 'Y' of HRESULT type.
  • V544. It is odd that the value 'X' of HRESULT type is compared with 'Y'.
  • V545. Such conditional expression of 'if' statement is incorrect for the HRESULT type value 'Foo'. The SUCCEEDED or FAILED macro should be used instead.
  • V546. Member of a class is initialized with itself: 'Foo(Foo)'.
  • V547. Expression is always true/false.
  • V548. Consider reviewing type casting. TYPE X[][] is not equivalent to TYPE **X.
  • V549. The 'first' argument of 'Foo' function is equal to the 'second' argument.
  • V550. An odd precise comparison. It's probably better to use a comparison with defined precision: fabs(A - B) < Epsilon or fabs(A - B) > Epsilon.
  • V551. The code under this 'case' label is unreachable.
  • V552. A bool type variable is being incremented. Perhaps another variable should be incremented instead.
  • V553. The length of function's body or class's declaration is more than 2000 lines long. You should consider refactoring the code.
  • V554. Incorrect use of smart pointer.
  • V555. The expression of the 'A - B > 0' kind will work as 'A != B'.
  • V556. The values of different enum types are compared.
  • V557. Array overrun is possible.
  • V558. Function returns the pointer/reference to temporary local object.
  • V559. Suspicious assignment inside the conditional expression of 'if/while/for' statement.
  • V560. A part of conditional expression is always true/false.
  • V561. It's probably better to assign value to 'foo' variable than to declare it anew.
  • V562. It's odd to compare a bool type value with a value of N.
  • V563. It is possible that this 'else' branch must apply to the previous 'if' statement.
  • V564. The '&' or '|' operator is applied to bool type value. You've probably forgotten to include parentheses or intended to use the '&&' or '||' operator.
  • V565. An empty exception handler. Silent suppression of exceptions can hide the presence of bugs in source code during testing.
  • V566. The integer constant is converted to pointer. Possibly an error or a bad coding style.
  • V567. The modification of a variable is unsequenced relative to another operation on the same variable. This may lead to undefined behavior.
  • V568. It's odd that the argument of sizeof() operator is the expression.
  • V569. Truncation of constant value.
  • V570. The variable is assigned to itself.
  • V571. Recurring check. This condition was already verified in previous line.
  • V572. It is odd that the object which was created using 'new' operator is immediately cast to another type.
  • V573. Uninitialized variable 'Foo' was used. The variable was used to initialize itself.
  • V574. The pointer is used simultaneously as an array and as a pointer to single object.
  • V575. Function receives an odd argument.
  • V576. Incorrect format. Consider checking the N actual argument of the 'Foo' function.
  • V577. Label is present inside a switch(). It is possible that these are misprints and 'default:' operator should be used instead.
  • V578. An odd bitwise operation detected. Consider verifying it.
  • V579. The 'Foo' function receives the pointer and its size as arguments. It is possibly a mistake. Inspect the N argument.
  • V580. An odd explicit type casting. Consider verifying it.
  • V581. The conditional expressions of the 'if' statements situated alongside each other are identical.
  • V582. Consider reviewing the source code which operates the container.
  • V583. The '?:' operator, regardless of its conditional expression, always returns one and the same value.
  • V584. The same value is present on both sides of the operator. The expression is incorrect or it can be simplified.
  • V585. An attempt to release the memory in which the 'Foo' local variable is stored.
  • V586. The 'Foo' function is called twice for deallocation of the same resource.
  • V587. An odd sequence of assignments of this kind: A = B; B = A;.
  • V588. The expression of the 'A =+ B' kind is utilized. Consider reviewing it, as it is possible that 'A += B' was meant.
  • V589. The expression of the 'A =- B' kind is utilized. Consider reviewing it, as it is possible that 'A -= B' was meant.
  • V590. Consider inspecting this expression. The expression is excessive or contains a misprint.
  • V591. Non-void function should return a value.
  • V592. The expression was enclosed by parentheses twice: ((expression)). One pair of parentheses is unnecessary or misprint is present.
  • V593. Consider reviewing the expression of the 'A = B == C' kind. The expression is calculated as following: 'A = (B == C)'.
  • V594. The pointer steps out of array's bounds.
  • V595. The pointer was utilized before it was verified against nullptr. Check lines: N1, N2.
  • V596. The object was created but it is not being used. The 'throw' keyword could be missing.
  • V597. The compiler could delete the 'memset' function call, which is used to flush 'Foo' buffer. The RtlSecureZeroMemory() function should be used to erase the private data.
  • V598. The 'memset/memcpy' function is used to nullify/copy the fields of 'Foo' class. Virtual table pointer will be damaged by this.
  • V599. The virtual destructor is not present, although the 'Foo' class contains virtual functions.
  • V600. Consider inspecting the condition. The 'Foo' pointer is always not equal to NULL.
  • V601. An odd implicit type casting.
  • V602. Consider inspecting this expression. '<' possibly should be replaced with '<<'.
  • V603. The object was created but it is not being used. If you wish to call constructor, 'this->Foo::Foo(....)' should be used.
  • V604. It is odd that the number of iterations in the loop equals to the size of the pointer.
  • V605. Consider verifying the expression. An unsigned value is compared to the number - NN.
  • V606. Ownerless token 'Foo'.
  • V607. Ownerless expression 'Foo'.
  • V608. Recurring sequence of explicit type casts.
  • V609. Divide or mod by zero.
  • V610. Undefined behavior. Check the shift operator.
  • V611. The memory allocation and deallocation methods are incompatible.
  • V612. An unconditional 'break/continue/return/goto' within a loop.
  • V613. Strange pointer arithmetic with 'malloc/new'.
  • V614. Uninitialized variable 'Foo' used.
  • V615. An odd explicit conversion from 'float *' type to 'double *' type.
  • V616. The 'Foo' named constant with the value of 0 is used in the bitwise operation.
  • V617. Consider inspecting the condition. An argument of the '|' bitwise operation always contains a non-zero value.
  • V618. It's dangerous to call the 'Foo' function in such a manner, as the line being passed could contain format specification. The example of the safe code: printf("%s", str);
  • V619. An array is being utilized as a pointer to single object.
  • V620. It's unusual that the expression of sizeof(T)*N kind is being summed with the pointer to T type.
  • V621. Consider inspecting the 'for' operator. It's possible that the loop will be executed incorrectly or won't be executed at all.
  • V622. Consider inspecting the 'switch' statement. It's possible that the first 'case' operator is missing.
  • V623. Consider inspecting the '?:' operator. A temporary object is being created and subsequently destroyed.
  • V624. The constant NN is being utilized. The resulting value could be inaccurate. Consider using the M_NN constant from <math.h>.
  • V625. Consider inspecting the 'for' operator. Initial and final values of the iterator are the same.
  • V626. Consider checking for misprints. It's possible that ',' should be replaced by ';'.
  • V627. Consider inspecting the expression. The argument of sizeof() is the macro which expands to a number.
  • V628. It's possible that the line was commented out improperly, thus altering the program's operation logics.
  • V629. Consider inspecting the expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type.
  • V630. The 'malloc' function is used to allocate memory for an array of objects which are classes containing constructors/destructors.
  • V631. Consider inspecting the 'Foo' function call. Defining an absolute path to the file or directory is considered a poor style.
  • V632. Consider inspecting the NN argument of the 'Foo' function. It is odd that the argument is of the 'T' type.
  • V633. Consider inspecting the expression. Probably the '!=' should be used here.
  • V634. The priority of the '+' operation is higher than that of the '<<' operation. It's possible that parentheses should be used in the expression.
  • V635. Consider inspecting the expression. The length should probably be multiplied by the sizeof(wchar_t).
  • V636. The expression was implicitly cast from integer type to real type. Consider utilizing an explicit type cast to avoid overflow or loss of a fractional part.
  • V637. Two opposite conditions were encountered. The second condition is always false.
  • V638. A terminal null is present inside a string. The '\0xNN' characters were encountered. Probably meant: '\xNN'.
  • V639. Consider inspecting the expression for function call. It is possible that one of the closing ')' parentheses was positioned incorrectly.
  • V640. The code's operational logic does not correspond with its formatting.
  • V641. The buffer size is not a multiple of the element size.
  • V642. Saving the function result inside the 'byte' type variable is inappropriate. The significant bits could be lost breaking the program's logic.
  • V643. Unusual pointer arithmetic. The value of the 'char' type is being added to the string pointer.
  • V644. A suspicious function declaration. It is possible that the T type object was meant to be created.
  • V645. The function call could lead to the buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold.
  • V646. Consider inspecting the application's logic. It's possible that 'else' keyword is missing.
  • V647. The value of 'A' type is assigned to the pointer of 'B' type.
  • V648. Priority of the '&&' operation is higher than that of the '||' operation.
  • V649. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains function return. This means that the second 'if' statement is senseless.
  • V650. Type casting operation is utilized 2 times in succession. Next, the '+' operation is executed. Probably meant: (T1)((T2)a + b).
  • V651. An odd operation of the 'sizeof(X)/sizeof(T)' kind is performed, where 'X' is of the 'class' type.
  • V652. The operation is executed 3 or more times in succession.
  • V653. A suspicious string consisting of two parts is used for the initialization. It is possible that a comma is missing.
  • V654. The condition of loop is always true/false.
  • V655. The strings were concatenated but are not utilized. Consider inspecting the expression.
  • V656. Variables are initialized through the call to the same function. It's probably an error or un-optimized code.
  • V657. It's odd that this function always returns one and the same value of NN.
  • V658. A value is being subtracted from the unsigned variable. This can result in an overflow. In such a case, the comparison operation can potentially behave unexpectedly.
  • V659. Declarations of functions with 'Foo' name differ in the 'const' keyword only, but the bodies of these functions have different composition. This is suspicious and can possibly be an error.
  • V660. The program contains an unused label and a function call: 'CC:AA()'. It's possible that the following was intended: 'CC::AA()'.
  • V661. A suspicious expression 'A[B < C]'. Probably meant 'A[B] < C'.
  • V662. Consider inspecting the loop expression. Different containers are utilized for setting up initial and final values of the iterator.
  • V663. Infinite loop is possible. The 'cin.eof()' condition is insufficient to break from the loop. Consider adding the 'cin.fail()' function call to the conditional expression.
  • V664. The pointer is being dereferenced on the initialization list before it is verified against null inside the body of the constructor function.
  • V665. Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The '#pragma warning(push/pop)' should be used instead.
  • V666. Consider inspecting NN argument of the function 'Foo'. It is possible that the value does not correspond with the length of a string which was passed with the YY argument.
  • V667. The 'throw' operator does not possess any arguments and is not situated within the 'catch' block.
  • V668. There is no sense in testing the pointer against null, as the memory was allocated using the 'new' operator. The exception will be generated in the case of memory allocation error.
  • V669. The argument is a non-constant reference. The analyzer is unable to determine the position at which this argument is being modified. It is possible that the function contains an error.
  • V670. An uninitialized class member is used to initialize another member. Remember that members are initialized in the order of their declarations inside a class.
  • V671. It is possible that the 'swap' function interchanges a variable with itself.
  • V672. There is probably no need in creating a new variable here. One of the function's arguments possesses the same name and this argument is a reference.
  • V673. More than N bits are required to store the value, but the expression evaluates to the T type which can only hold K bits.
  • V674. The expression contains a suspicious mix of integer and real types.
  • V675. Writing into the read-only memory.
  • V676. It is incorrect to compare the variable of BOOL type with TRUE.
  • V677. Custom declaration of a standard type. The declaration from system header files should be used instead.
  • V678. An object is used as an argument to its own method. Consider checking the first actual argument of the 'Foo' function.
  • V679. The 'X' variable was not initialized. This variable is passed by a reference to the 'Foo' function in which its value will be utilized.
  • V680. The 'delete A, B' expression only destroys the 'A' object. Then the ',' operator returns a resulting value from the right side of the expression.
  • V681. The language standard does not define an order in which the 'Foo' functions will be called during evaluation of arguments.
  • V682. Suspicious literal is present: '/r'. It is possible that a backslash should be used here instead: '\r'.
  • V683. Consider inspecting the loop expression. It is possible that the 'i' variable should be incremented instead of the 'n' variable.
  • V684. A value of variable is not modified. Consider inspecting the expression. It is possible that '1' should be present instead of '0'.
  • V685. Consider inspecting the return statement. The expression contains a comma.
  • V686. A pattern was detected: A || (A && ...). The expression is excessive or contains a logical error.
  • V687. Size of an array calculated by the sizeof() operator was added to a pointer. It is possible that the number of elements should be calculated by sizeof(A)/sizeof(A[0]).
  • V688. The 'foo' local variable possesses the same name as one of the class members, which can result in a confusion.
  • V689. The destructor of the 'Foo' class is not declared as a virtual. It is possible that a smart pointer will not destroy an object correctly.
  • V690. The class implements a copy constructor/operator=, but lacks the operator=/copy constructor.
  • V691. Empirical analysis. It is possible that a typo is present inside the string literal. The 'foo' word is suspicious.
  • V692. An inappropriate attempt to append a null character to a string. To determine the length of a string by 'strlen' function correctly, a string ending with a null terminator should be used in the first place.
  • V693. Consider inspecting conditional expression of the loop. It is possible that 'i < X.size()' should be used instead of 'X.size()'.
  • V694. The condition (ptr - const_value) is only false if the value of a pointer equals a magic constant.
  • V695. Range intersections are possible within conditional expressions.
  • V696. The 'continue' operator will terminate 'do { ... } while (FALSE)' loop because the condition is always false.
  • V697. A number of elements in the allocated array is equal to size of a pointer in bytes.
  • V698. strcmp()-like functions can return not only the values -1, 0 and 1, but any values.
  • V699. Consider inspecting the 'foo = bar = baz ? .... : ....' expression. It is possible that 'foo = bar == baz ? .... : ....' should be used here instead.
  • V700. Consider inspecting the 'T foo = foo = x;' expression. It is odd that variable is initialized through itself.
  • V701. realloc() possible leak: when realloc() fails in allocating memory, original pointer is lost. Consider assigning realloc() to a temporary pointer.
  • V702. Classes should always be derived from std::exception (and alike) as 'public'.
  • V703. It is odd that the 'foo' field in derived class overwrites field in base class.
  • V704. The 'this == 0' comparison should be avoided - this comparison is always false on newer compilers.
  • V705. It is possible that 'else' block was forgotten or commented out, thus altering the program's operation logics.
  • V706. Suspicious division: sizeof(X) / Value. Size of every element in X array does not equal to divisor.
  • V707. Giving short names to global variables is considered to be bad practice.
  • V708. Dangerous construction is used: 'm[x] = m.size()', where 'm' is of 'T' class. This may lead to undefined behavior.
  • V709. Suspicious comparison found: 'a == b == c'. Remember that 'a == b == c' is not equal to 'a == b && b == c'.
  • V710. Suspicious declaration found. There is no point to declare constant reference to a number.
  • V711. It is dangerous to create a local variable within a loop with a same name as a variable controlling this loop.
  • V712. Be advised that compiler may delete this cycle or make it infinity. Use volatile variable(s) or synchronization primitives to avoid this.
  • V713. The pointer was utilized in the logical expression before it was verified against nullptr in the same logical expression.
  • V714. Variable is not passed into foreach loop by a reference, but its value is changed inside of the loop.
  • V715. The 'while' operator has empty body. Suspicious pattern detected.
  • V716. Suspicious type conversion: HRESULT -> BOOL (BOOL -> HRESULT).
  • V717. It is suspicious to cast object of base class V to derived class U.
  • V718. The 'Foo' function should not be called from 'DllMain' function.
  • V719. The switch statement does not cover all values of the enum.
  • V720. It is advised to utilize the 'SuspendThread' function only when developing a debugger (see documentation for details).
  • V721. The VARIANT_BOOL type is utilized incorrectly. The true value (VARIANT_TRUE) is defined as -1.
  • V722. An abnormality within similar comparisons. It is possible that a typo is present inside the expression.
  • V723. Function returns a pointer to the internal string buffer of a local object, which will be destroyed.
  • V724. Converting integers or pointers to BOOL can lead to a loss of high-order bits. Non-zero value can become 'FALSE'.
  • V725. A dangerous cast of 'this' to 'void*' type in the 'Base' class, as it is followed by a subsequent cast to 'Class' type.
  • V726. An attempt to free memory containing the 'int A[10]' array by using the 'free(A)' function.
  • V727. Return value of 'wcslen' function is not multiplied by 'sizeof(wchar_t)'.
  • V728. An excessive check can be simplified. The '||' operator is surrounded by opposite expressions 'x' and '!x'.
  • V729. Function body contains the 'X' label that is not used by any 'goto' statements.
  • V730. Not all members of a class are initialized inside the constructor.
  • V731. The variable of char type is compared with pointer to string.
  • V732. Unary minus operator does not modify a bool type value.
  • V733. It is possible that macro expansion resulted in incorrect evaluation order.
  • V734. An excessive expression. Examine the substrings "abc" and "abcd".
  • V735. Possibly an incorrect HTML. The "</XX>" closing tag was encountered, while the "</YY>" tag was expected.
  • V736. The behavior is undefined for arithmetic or comparisons with pointers that do not point to members of the same array.
  • V737. It is possible that ',' comma is missing at the end of the string.
  • V738. Temporary anonymous object is used.
  • V739. EOF should not be compared with a value of the 'char' type. Consider using the 'int' type.
  • V740. Because NULL is defined as 0, the exception is of the 'int' type. Keyword 'nullptr' could be used for 'pointer' type exception.
  • V741. The following pattern is used: throw (a, b);. It is possible that type name was omitted: throw MyException(a, b);.
  • V742. Function receives an address of a 'char' type variable instead of pointer to a buffer.
  • V743. The memory areas must not overlap. Use 'memmove' function.
  • V744. Temporary object is immediately destroyed after being created. Consider naming the object.
  • V745. A 'wchar_t *' type string is incorrectly converted to 'BSTR' type string.
  • V746. Object slicing. An exception should be caught by reference rather than by value.
  • V747. An odd expression inside parenthesis. It is possible that a function name is missing.
  • V748. Memory for 'getline' function should be allocated only by 'malloc' or 'realloc' functions. Consider inspecting the first parameter of 'getline' function.
  • V749. Destructor of the object will be invoked a second time after leaving the object's scope.
  • V750. BSTR string becomes invalid. Notice that BSTR strings store their length before start of the text.
  • V751. Parameter is not used inside function's body.
  • V752. Creating an object with placement new requires a buffer of large size.
  • V753. The '&=' operation always sets a value of 'Foo' variable to zero.
  • V754. The expression of 'foo(foo(x))' pattern is excessive or contains an error.
  • V755. Copying from unsafe data source. Buffer overflow is possible.
  • V756. The 'X' counter is not used inside a nested loop. Consider inspecting usage of 'Y' counter.
  • V757. It is possible that an incorrect variable is compared with null after type conversion using 'dynamic_cast'.
  • V758. Reference invalidated because of the destruction of the temporary object returned by the function.
  • V759. Violated order of exception handlers. Exception caught by handler for base class.
  • V760. Two identical text blocks detected. The second block starts with NN string.
  • V761. NN identical blocks were found.
  • V762. Consider inspecting virtual function arguments. See NN argument of function 'Foo' in derived class and base class.
  • V763. Parameter is always rewritten in function body before being used.
  • V764. Possible incorrect order of arguments passed to function.
  • V765. A compound assignment expression 'X += X + N' is suspicious. Consider inspecting it for a possible error.
  • V766. An item with the same key has already been added.
  • V767. Suspicious access to element by a constant index inside a loop.
  • V768. The variable is of enum type. It is odd that it is used as a variable of a Boolean-type.
  • V769. The pointer in the expression equals nullptr. The resulting value is meaningless and should not be used.
  • V770. Possible use of a left shift operator instead of a comparison operator.
  • V771. The '?:' operator uses constants from different enums.
  • V772. Calling the 'delete' operator for a void pointer will cause undefined behavior.
  • V773. The function was exited without releasing the pointer/handle. A memory/resource leak is possible.
  • V774. The pointer was used after the memory was released.
  • V775. It is odd that the BSTR data type is compared using a relational operator.
  • V776. Potentially infinite loop. The variable in the loop exit condition does not change its value between iterations.
  • V777. Dangerous widening type conversion from an array of derived-class objects to a base-class pointer.
  • V778. Two similar code fragments were found. Perhaps, this is a typo and 'X' variable should be used instead of 'Y'.
  • V779. Unreachable code detected. It is possible that an error is present.
  • V780. The object of non-passive (non-PDS) type cannot be used with the function.
  • V781. The value of the variable is checked after it was used. Perhaps there is a mistake in program logic. Check lines: N1, N2.
  • V782. It is pointless to compute the distance between the elements of different arrays.
  • V783. Dereferencing of invalid iterator 'X' might take place.
  • V784. The size of the bit mask is less than the size of the first operand. This will cause the loss of the higher bits.
  • V785. Constant expression in switch statement.
  • V786. Assigning the value C to the X variable looks suspicious. The value range of the variable: [A, B].
  • V787. A wrong variable is probably used as an index in the for statement.
  • V788. Review captured variable in lambda expression.
  • V789. Iterators for the container, used in the range-based for loop, become invalid upon a function call.
  • V790. It is odd that the assignment operator takes an object by a non-constant reference and returns this object.
  • V791. The initial value of the index in the nested loop equals 'i'. Consider using 'i + 1' instead.
  • V792. The function located to the right of the '|' and '&' operators will be called regardless of the value of the left operand. Consider using '||' and '&&' instead.
  • V793. It is odd that the result of the statement is a part of the condition. Perhaps, this statement should have been compared with something else.
  • V794. The assignment operator should be protected from the case of this == &src.
  • V795. Note that the size of the 'time_t' type is not 64 bits. After the year 2038, the program will work incorrectly.
  • V796. A 'break' statement is probably missing in a 'switch' statement.
  • V797. The function is used as if it returned a bool type. The return value of the function should probably be compared with std::string::npos.
  • V798. The size of the dynamic array can be less than the number of elements in the initializer.
  • V799. The variable is not used after memory has been allocated for it. Consider checking the use of this variable.
  • V1001. The variable is assigned but is not used by the end of the function.
  • V1002. A class, containing pointers, constructor and destructor, is copied by the automatically generated operator= or copy constructor.
  • V1003. The macro expression is dangerous, or it is suspicious.
  • V1004. The pointer was used unsafely after it was verified against nullptr.
  • V1005. The resource was acquired using 'X' function but was released using incompatible 'Y' function.
  • V1006. Several shared_ptr objects are initialized by the same pointer. A double memory deallocation will occur.
  • V1007. The value from the uninitialized optional is used. Probably it is a mistake.
  • V1008. Consider inspecting the 'for' operator. No more than one iteration of the loop will be performed.
  • V1009. Check the array initialization. Only the first element is initialized explicitly.
  • V1010. Unchecked tainted data is used in expression.
  • V1011. Function execution could be deferred. Consider specifying execution policy explicitly.
  • V1012. The expression is always false. Overflow check is incorrect.
  • V1013. Suspicious subexpression in a sequence of similar comparisons.
  • V1014. Structures with members of real type are compared byte-wise.
  • V1015. Suspicious simultaneous use of bitwise and logical operators.
  • V1016. The value is out of range of enum values. This causes unspecified or undefined behavior.
  • V1017. Variable of the 'string_view' type references a temporary object which will be removed after evaluation of an expression.
  • V1018. Usage of a suspicious mutex wrapper. It is probably unused, uninitialized, or already locked.
  • V1019. Compound assignment expression is used inside condition.
  • V1020. Function exited without performing epilogue actions. It is possible that there is an error.
  • V1021. The variable is assigned the same value on several loop iterations.
  • V1022. An exception was thrown by pointer. Consider throwing it by value instead.
  • V1023. A pointer without owner is added to the container by the 'emplace_back' method. A memory leak will occur in case of an exception.
  • V1024. The stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
  • V1025. Rather than creating 'std::unique_lock' to lock on the mutex, a new variable with default value is created.
  • V1026. The variable is incremented in the loop. Undefined behavior will occur in case of signed integer overflow.
  • V1027. Pointer to an object of the class is cast to unrelated class.
  • V1028. Possible overflow. Consider casting operands, not the result.
  • V1029. Numeric Truncation Error. Return value of function is written to N-bit variable.
  • V1030. The variable is used after it was moved.
  • V1031. Function is not declared. The passing of data to or from this function may be affected.
  • V1032. Pointer is cast to a more strictly aligned pointer type.
  • V1033. Variable is declared as auto in C. Its default type is int.
  • V1034. Do not use real-type variables as loop counters.
  • V1035. Only values that are returned from fgetpos() can be used as arguments to fsetpos().
  • V1036. Potentially unsafe double-checked locking.
  • V1037. Two or more case-branches perform the same actions.
  • V1038. It's odd that a char or string literal is added to a pointer.
  • V1039. Character escape is used in multicharacter literal. This causes implementation-defined behavior.
  • V1040. Possible typo in the spelling of a pre-defined macro name.
  • V1041. Class member is initialized with dangling reference.
  • V1042. This file is marked with copyleft license, which requires you to open the derived source code.
  • V1043. A global object variable is declared in the header. Multiple copies of it will be created in all translation units that include this header file.
  • V1044. Loop break conditions do not depend on the number of iterations.
  • V1045. The DllMain function throws an exception. Consider wrapping the throw operator in a try..catch block.
  • V1046. Unsafe usage of the 'bool' and integer types together in the operation '&='.
  • V1047. Lifetime of the lambda is greater than lifetime of the local variable captured by reference.
  • V1048. Variable 'foo' was assigned the same value.
  • V1049. The 'foo' include guard is already defined in the 'bar1.h' header. The 'bar2.h' header will be excluded from compilation.
  • V1050. The uninitialized class member is used when initializing the base class.
  • V1051. Consider checking for misprints. It's possible that an assigned variable should be checked in the next condition.
  • V1052. Declaring virtual methods in a class marked as 'final' is pointless.
  • V1053. Calling the 'foo' virtual function in the constructor/destructor may lead to unexpected result at runtime.
  • V1054. Object slicing. Derived class object was copied to the base class object.
  • V1055. The 'sizeof' expression returns the size of the container type, not the number of elements. Consider using the 'size()' function.
  • V1056. The predefined identifier '__func__' always contains the string 'operator()' inside function body of the overloaded 'operator()'.
  • V1057. Pseudo random sequence is the same at every program run. Consider assigning the seed to a value not known at compile-time.
  • V1058. Nonsensical comparison of two different functions' addresses.
  • V1059. Macro name overrides a keyword/reserved name. This may lead to undefined behavior.
  • V1060. Passing 'BSTR ' to the 'SysAllocString' function may lead to incorrect object creation.
  • V1061. Extending 'std' or 'posix' namespace may result in undefined behavior.
  • V1062. Class defines a custom new or delete operator. The opposite operator must also be defined.
  • V1063. The modulo by 1 operation is meaningless. The result will always be zero.
  • V1064. The left operand of integer division is less than the right one. The result will always be zero.

Диагностики общего назначения (General Analysis, C#)

  • V3001. There are identical sub-expressions to the left and to the right of the 'foo' operator.
  • V3002. The switch statement does not cover all values of the enum.
  • V3003. The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence.
  • V3004. The 'then' statement is equivalent to the 'else' statement.
  • V3005. The 'x' variable is assigned to itself.
  • V3006. The object was created but it is not being used. The 'throw' keyword could be missing.
  • V3007. Odd semicolon ';' after 'if/for/while' operator.
  • V3008. The 'x' variable is assigned values twice successively. Perhaps this is a mistake.
  • V3009. It's odd that this method always returns one and the same value of NN.
  • V3010. The return value of function 'Foo' is required to be utilized.
  • V3011. Two opposite conditions were encountered. The second condition is always false.
  • V3012. The '?:' operator, regardless of its conditional expression, always returns one and the same value.
  • V3013. It is odd that the body of 'Foo_1' function is fully equivalent to the body of 'Foo_2' function.
  • V3014. It is likely that a wrong variable is being incremented inside the 'for' operator. Consider reviewing 'X'.
  • V3015. It is likely that a wrong variable is being compared inside the 'for' operator. Consider reviewing 'X'.
  • V3016. The variable 'X' is being used for this loop and for the outer loop.
  • V3017. A pattern was detected: A || (A && ...). The expression is excessive or contains a logical error.
  • V3018. Consider inspecting the application's logic. It's possible that 'else' keyword is missing.
  • V3019. It is possible that an incorrect variable is compared with null after type conversion using 'as' keyword.
  • V3020. An unconditional 'break/continue/return/goto' within a loop.
  • V3021. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless.
  • V3022. Expression is always true/false.
  • V3023. Consider inspecting this expression. The expression is excessive or contains a misprint.
  • V3024. An odd precise comparison. Consider using a comparison with defined precision: Math.Abs(A - B) < Epsilon or Math.Abs(A - B) > Epsilon.
  • V3025. Incorrect format. Consider checking the N format items of the 'Foo' function.
  • V3026. The constant NN is being utilized. The resulting value could be inaccurate. Consider using the KK constant.
  • V3027. The variable was utilized in the logical expression before it was verified against null in the same logical expression.
  • V3028. Consider inspecting the 'for' operator. Initial and final values of the iterator are the same.
  • V3029. The conditional expressions of the 'if' statements situated alongside each other are identical.
  • V3030. Recurring check. This condition was already verified in previous line.
  • V3031. An excessive check can be simplified. The operator '||' operator is surrounded by opposite expressions 'x' and '!x'.
  • V3032. Waiting on this expression is unreliable, as compiler may optimize some of the variables. Use volatile variable(s) or synchronization primitives to avoid this.
  • V3033. It is possible that this 'else' branch must apply to the previous 'if' statement.
  • V3034. Consider inspecting the expression. Probably the '!=' should be used here.
  • V3035. Consider inspecting the expression. Probably the '+=' should be used here.
  • V3036. Consider inspecting the expression. Probably the '-=' should be used here.
  • V3037. An odd sequence of assignments of this kind: A = B; B = A;
  • V3038. The argument was passed to method several times. It is possible that another argument should be passed instead.
  • V3039. Consider inspecting the 'Foo' function call. Defining an absolute path to the file or directory is considered a poor style.
  • V3040. The expression contains a suspicious mix of integer and real types.
  • V3041. The expression was implicitly cast from integer type to real type. Consider utilizing an explicit type cast to avoid the loss of a fractional part.
  • V3042. Possible NullReferenceException. The '?.' and '.' operators are used for accessing members of the same object.
  • V3043. The code's operational logic does not correspond with its formatting.
  • V3044. WPF: writing and reading are performed on a different Dependency Properties.
  • V3045. WPF: the names of the property registered for DependencyProperty, and of the property used to access it, do not correspond with each other.
  • V3046. WPF: the type registered for DependencyProperty does not correspond with the type of the property used to access it.
  • V3047. WPF: A class containing registered property does not correspond with a type that is passed as the ownerType.type.
  • V3048. WPF: several Dependency Properties are registered with a same name within the owner type.
  • V3049. WPF: readonly field of 'DependencyProperty' type is not initialized.
  • V3050. Possibly an incorrect HTML. The </XX> closing tag was encountered, while the </YY> tag was expected.
  • V3051. An excessive type cast or check. The object is already of the same type.
  • V3052. The original exception object was swallowed. Stack of original exception could be lost.
  • V3053. An excessive expression. Examine the substrings "abc" and "abcd".
  • V3054. Potentially unsafe double-checked locking. Use volatile variable(s) or synchronization primitives to avoid this.
  • V3055. Suspicious assignment inside the condition expression of 'if/while/for' operator.
  • V3056. Consider reviewing the correctness of 'X' item's usage.
  • V3057. Function receives an odd argument.
  • V3058. An item with the same key has already been added.
  • V3059. Consider adding '[Flags]' attribute to the enum.
  • V3060. A value of variable is not modified. Consider inspecting the expression. It is possible that other value should be present instead of '0'.
  • V3061. Parameter 'A' is always rewritten in method body before being used.
  • V3062. An object is used as an argument to its own method. Consider checking the first actual argument of the 'Foo' method.
  • V3063. A part of conditional expression is always true/false if it is evaluated.
  • V3064. Division or mod division by zero.
  • V3065. Parameter is not utilized inside method's body.
  • V3066. Possible incorrect order of arguments passed to method.
  • V3067. It is possible that 'else' block was forgotten or commented out, thus altering the program's operation logics.
  • V3068. Calling overrideable class member from constructor is dangerous.
  • V3069. It's possible that the line was commented out improperly, thus altering the program's operation logics.
  • V3070. Uninitialized variables are used when initializing the 'A' variable.
  • V3071. The object is returned from inside 'using' block. 'Dispose' will be invoked before exiting method.
  • V3072. The 'A' class containing IDisposable members does not itself implement IDisposable.
  • V3073. Not all IDisposable members are properly disposed. Call 'Dispose' when disposing 'A' class.
  • V3074. The 'A' class contains 'Dispose' method. Consider making it implement 'IDisposable' interface.
  • V3075. The operation is executed 2 or more times in succession.
  • V3076. Comparison with 'double.NaN' is meaningless. Use 'double.IsNaN()' method instead.
  • V3077. Property setter / event accessor does not utilize its 'value' parameter.
  • V3078. Original sorting order will be lost after repetitive call to 'OrderBy' method. Use 'ThenBy' method to preserve the original sorting.
  • V3079. The 'ThreadStatic' attribute is applied to a non-static 'A' field and will be ignored.
  • V3080. Possible null dereference.
  • V3081. The 'X' counter is not used inside a nested loop. Consider inspecting usage of 'Y' counter.
  • V3082. The 'Thread' object is created but is not started. It is possible that a call to 'Start' method is missing.
  • V3083. Unsafe invocation of event, NullReferenceException is possible. Consider assigning event to a local variable before invoking it.
  • V3084. Anonymous function is used to unsubscribe from event. No handlers will be unsubscribed, as a separate delegate instance is created for each anonymous function declaration.
  • V3085. The name of 'X' field/property in a nested type is ambiguous. The outer type contains static field/property with identical name.
  • V3086. Variables are initialized through the call to the same function. It's probably an error or un-optimized code.
  • V3087. Type of variable enumerated in 'foreach' is not guaranteed to be castable to the type of collection's elements.
  • V3088. The expression was enclosed by parentheses twice: ((expression)). One pair of parentheses is unnecessary or misprint is present.
  • V3089. Initializer of a field marked by [ThreadStatic] attribute will be called once on the first accessing thread. The field will have default value on different threads.
  • V3090. Unsafe locking on an object.
  • V3091. Empirical analysis. It is possible that a typo is present inside the string literal. The 'foo' word is suspicious.
  • V3092. Range intersections are possible within conditional expressions.
  • V3093. The operator evaluates both operands. Perhaps a short-circuit operator should be used instead.
  • V3094. Possible exception when deserializing type. The Ctor(SerializationInfo, StreamingContext) constructor is missing.
  • V3095. The object was used before it was verified against null. Check lines: N1, N2.
  • V3096. Possible exception when serializing type. [Serializable] attribute is missing.
  • V3097. Possible exception: type marked by [Serializable] contains non-serializable members not marked by [NonSerialized].
  • V3098. The 'continue' operator will terminate 'do { ... } while (false)' loop because the condition is always false.
  • V3099. Not all the members of type are serialized inside 'GetObjectData' method.
  • V3100. NullReferenceException is possible. Unhandled exceptions in destructor lead to termination of runtime.
  • V3101. Potential resurrection of 'this' object instance from destructor. Without re-registering for finalization, destructor will not be called a second time on resurrected object.
  • V3102. Suspicious access to element by a constant index inside a loop.
  • V3103. A private Ctor(SerializationInfo, StreamingContext) constructor in unsealed type will not be accessible when deserializing derived types.
  • V3104. The 'GetObjectData' implementation in unsealed type is not virtual, incorrect serialization of derived type is possible.
  • V3105. The 'a' variable was used after it was assigned through null-conditional operator. NullReferenceException is possible.
  • V3106. Possibly index is out of bound.
  • V3107. Identical expression to the left and to the right of compound assignment.
  • V3108. It is not recommended to return null or throw exceptions from 'ToString()' method.
  • V3109. The same sub-expression is present on both sides of the operator. The expression is incorrect or it can be simplified.
  • V3110. Possible infinite recursion.
  • V3111. Checking value for null will always return false when generic type is instantiated with a value type.
  • V3112. An abnormality within similar comparisons. It is possible that a typo is present inside the expression.
  • V3113. Consider inspecting the loop expression. It is possible that different variables are used inside initializer and iterator.
  • V3114. IDisposable object is not disposed before method returns.
  • V3115. It is not recommended to throw exceptions from 'Equals(object obj)' method.
  • V3116. Consider inspecting the 'for' operator. It's possible that the loop will be executed incorrectly or won't be executed at all.
  • V3117. Constructor parameter is not used.
  • V3118. A component of TimeSpan is used, which does not represent full time interval. Possibly 'Total*' value was intended instead.
  • V3119. Calling a virtual (overridden) event may lead to unpredictable behavior. Consider implementing event accessors explicitly or use 'sealed' keyword.
  • V3120. Potentially infinite loop. The variable from the loop exit condition does not change its value between iterations.
  • V3121. An enumeration was declared with 'Flags' attribute, but does not set any initializers to override default values.
  • V3122. Uppercase (lowercase) string is compared with a different lowercase (uppercase) string.
  • V3123. Perhaps the '??' operator works in a different way than it was expected. Its priority is lower than priority of other operators in its left part.
  • V3124. Appending an element and checking for key uniqueness is performed on two different variables.
  • V3125. The object was used after it was verified against null. Check lines: N1, N2.
  • V3126. Type implementing IEquatable<T> interface does not override 'GetHashCode' method.
  • V3127. Two similar code fragments were found. Perhaps, this is a typo and 'X' variable should be used instead of 'Y'.
  • V3128. The field (property) is used before it is initialized in constructor.
  • V3129. The value of the captured variable will be overwritten on the next iteration of the loop in each instance of anonymous function that captures it.
  • V3130. Priority of the '&&' operator is higher than that of the '||' operator. Possible missing parentheses.
  • V3131. The expression is checked for compatibility with the type 'A', but is casted to the 'B' type.
  • V3132. A terminal null is present inside a string. The '\0xNN' characters were encountered. Probably meant: '\xNN'.
  • V3133. Postfix increment/decrement is senseless because this variable is overwritten.
  • V3134. Shift by N bits is greater than the size of type.
  • V3135. The initial value of the index in the nested loop equals 'i'. Consider using 'i + 1' instead.
  • V3136. Constant expression in switch statement.
  • V3137. The variable is assigned but is not used by the end of the function.
  • V3138. String literal contains potential interpolated expression.
  • V3139. Two or more case-branches perform the same actions.
  • V3140. Property accessors use different backing fields.
  • V3141. Expression under 'throw' is a potential null, which can lead to NullReferenceException.
  • V3142. Unreachable code detected. It is possible that an error is present.
  • V3143. The 'value' parameter is rewritten inside a property setter, and is not used after that.
  • V3144. This file is marked with copyleft license, which requires you to open the derived source code.
  • V3145. Unsafe dereference of a WeakReference target. The object could have been garbage collected before the 'Target' property was accessed.
  • V3146. Possible null dereference. A method can return default null value.
  • V3147. Non-atomic modification of volatile variable.
  • V3148. Casting potential 'null' value to a value type can lead to NullReferenceException.
  • V3149. Dereferencing the result of 'as' operator can lead to NullReferenceException.
  • V3150. Loop break conditions do not depend on the number of iterations.
  • V3151. Potential division by zero. Variable was used as a divisor before it was compared to zero. Check lines: N1, N2.
  • V3152. Potential division by zero. Variable was compared to zero before it was used as a divisor. Check lines: N1, N2.
  • V3153. Dereferencing the result of null-conditional access operator can lead to NullReferenceException. Consider removing parentheses around null-conditional access expression.
  • V3154. The 'a % b' expression always evaluates to 0.
  • V3155. The expression is incorrect or it can be simplified.
  • V3156. The argument of the method is not expected to be null.
  • V3157. Suspicious division. Absolute value of the left operand is less than the right operand.
  • V3158. Suspicious division. Absolute values of both operands are equal.

Диагностики общего назначения (General Analysis, Java)

  • V6001. There are identical sub-expressions to the left and to the right of the 'foo' operator.
  • V6002. The switch statement does not cover all values of the enum.
  • V6003. The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence.
  • V6004. The 'then' statement is equivalent to the 'else' statement.
  • V6005. The 'x' variable is assigned to itself.
  • V6006. The object was created but it is not being used. The 'throw' keyword could be missing.
  • V6007. Expression is always true/false.
  • V6008. Potential null dereference.
  • V6009. Function receives an odd argument.
  • V6010. The return value of function 'Foo' is required to be utilized.
  • V6011. The expression contains a suspicious mix of integer and real types.
  • V6012. The '?:' operator, regardless of its conditional expression, always returns one and the same value.
  • V6013. Comparison of arrays, strings, collections by reference. Possibly an equality comparison was intended.
  • V6014. It's odd that this method always returns one and the same value of NN.
  • V6015. Consider inspecting the expression. Probably the '!='/'-='/'+=' should be used here.
  • V6016. Suspicious access to element by a constant index inside a loop.
  • V6017. The 'X' counter is not used inside a nested loop. Consider inspecting usage of 'Y' counter.
  • V6018. Constant expression in switch statement.
  • V6019. Unreachable code detected. It is possible that an error is present.
  • V6020. Division or mod division by zero.
  • V6021. The value is assigned to the 'x' variable but is not used.
  • V6022. Parameter is not used inside method's body.
  • V6023. Parameter 'A' is always rewritten in method body before being used.
  • V6024. The 'continue' operator will terminate 'do { ... } while (false)' loop because the condition is always false.
  • V6025. Possibly index is out of bound.
  • V6026. This value is already assigned to the 'b' variable.
  • V6027. Variables are initialized through the call to the same function. It's probably an error or un-optimized code.
  • V6028. Identical expression to the left and to the right of compound assignment.
  • V6029. Possible incorrect order of arguments passed to method.
  • V6030. The function located to the right of the '|' and '&' operators will be called regardless of the value of the left operand. Consider using '||' and '&&' instead.
  • V6031. The variable 'X' is being used for this loop and for the outer loop.
  • V6032. It is odd that the body of 'Foo_1' function is fully equivalent to the body of 'Foo_2' function.
  • V6033. An item with the same key has already been added.
  • V6034. Shift by N bits is inconsistent with the size of type.
  • V6035. Double negation is present in the expression: !!x.
  • V6036. The value from the uninitialized optional is used.
  • V6037. An unconditional 'break/continue/return/goto' within a loop.
  • V6038. Comparison with 'double.NaN' is meaningless. Use 'double.isNaN()' method instead.
  • V6039. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless.
  • V6040. The code's operational logic does not correspond with its formatting.
  • V6041. Suspicious assignment inside the conditional expression of 'if/while/do...while' statement.
  • V6042. The expression is checked for compatibility with type 'A', but is cast to type 'B'.
  • V6043. Consider inspecting the 'for' operator. Initial and final values of the iterator are the same.
  • V6044. Postfix increment/decrement is senseless because this variable is overwritten.
  • V6045. Suspicious subexpression in a sequence of similar comparisons.
  • V6046. Incorrect format. Consider checking the N format items of the 'Foo' function.
  • V6047. It is possible that this 'else' branch must apply to the previous 'if' statement.
  • V6048. This expression can be simplified. One of the operands in the operation equals NN. Probably it is a mistake.
  • V6049. Classes that define 'equals' method must also define 'hashCode' method.
  • V6050. Class initialization cycle is present.
  • V6051. Use of jump statements in 'finally' block can lead to the loss of unhandled exceptions.
  • V6052. Calling an overridden method in parent-class constructor may lead to use of uninitialized data.
  • V6053. Collection is modified while iteration is in progress. ConcurrentModificationException may occur.
  • V6054. Classes should not be compared by their name.
  • V6055. Expression inside assert statement can change object's state.
  • V6056. Implementation of 'compareTo' overloads the method from a base class. Possibly, an override was intended.
  • V6057. Consider inspecting this expression. The expression is excessive or contains a misprint.
  • V6058. Comparing objects of incompatible types.
  • V6059. Odd use of special character in regular expression. Possibly, it was intended to be escaped.
  • V6060. The reference was used before it was verified against null.
  • V6061. The used constant value is represented by an octal form.
  • V6062. Possible infinite recursion.
  • V6063. Odd semicolon ';' after 'if/foreach' operator.
  • V6064. Suspicious invocation of Thread.run().
  • V6065. A non-serializable class should not be serialized.
  • V6066. Passing objects of incompatible types to the method of collection.
  • V6067. Two or more case-branches perform the same actions.
  • V6068. Suspicious use of BigDecimal class.
  • V6069. Unsigned right shift assignment of negative 'byte' / 'short' value.
  • V6070. Unsafe synchronization on an object.
  • V6071. This file is marked with copyleft license, which requires you to open the derived source code.
  • V6072. Two similar code fragments were found. Perhaps, this is a typo and 'X' variable should be used instead of 'Y'.
  • V6073. It is not recommended to return null or throw exceptions from 'toString' / 'clone' methods.
  • V6074. Non-atomic modification of volatile variable.
  • V6075. The signature of method 'X' does not conform to serialization requirements.
  • V6076. Recurrent serialization will use cached object state from first serialization.
  • V6077. A suspicious label is present inside a switch(). It is possible that these are misprints and 'default:' label should be used instead.
  • V6078. Potential Java SE API compatibility issue.
  • V6079. Value of variable is checked after use. Potential logical error is present. Check lines: N1, N2.
  • V6080. Consider checking for misprints. It's possible that an assigned variable should be checked in the next condition.
  • V6081. Annotation that does not have 'RUNTIME' retention policy will not be accessible through Reflection API.
  • V6082. Unsafe double-checked locking.
  • V6083. Serialization order of fields should be preserved during deserialization.
  • V6084. Suspicious return of an always empty collection.
  • V6085. An abnormality within similar comparisons. It is possible that a typo is present inside the expression.
  • V6086. Suspicious code formatting. 'else' keyword is probably missing.
  • V6087. InvalidClassException may occur during deserialization.
  • V6088. Result of this expression will be implicitly cast to 'Type'. Check if program logic handles it correctly.
  • V6089. It's possible that the line was commented out improperly, thus altering the program's operation logics.
  • V6090. Field 'A' is being used before it was initialized.
  • V6091. Suspicious getter/setter implementation. The 'A' field should probably be returned/assigned instead.
  • V6092. A resource is returned from try-with-resources statement. It will be closed before the method exits.
  • V6093. Automatic unboxing of a variable may cause NullPointerException.
  • V6094. The expression was implicitly cast from integer type to real type. Consider utilizing an explicit type cast to avoid the loss of a fractional part.

Диагностика микро-оптимизаций (C++)

  • V801. Decreased performance. It is better to redefine the N function argument as a reference. Consider replacing 'const T' with 'const .. &T' / 'const .. *T'.
  • V802. On 32-bit/64-bit platform, structure size can be reduced from N to K bytes by rearranging the fields according to their sizes in decreasing order.
  • V803. Decreased performance. It is more effective to use the prefix form of ++it. Replace iterator++ with ++iterator.
  • V804. Decreased performance. The 'Foo' function is called twice in the specified expression to calculate length of the same string.
  • V805. Decreased performance. It is inefficient to identify an empty string by using 'strlen(str) > 0' construct. A more efficient way is to check: str[0] != '\0'.
  • V806. Decreased performance. The expression of strlen(MyStr.c_str()) kind can be rewritten as MyStr.length().
  • V807. Decreased performance. Consider creating a pointer/reference to avoid using the same expression repeatedly.
  • V808. An array/object was declared but was not utilized.
  • V809. Verifying that a pointer value is not NULL is not required. The 'if (ptr != NULL)' check can be removed.
  • V810. Decreased performance. The 'A' function was called several times with identical arguments. The result should possibly be saved to a temporary variable, which then could be used while calling the 'B' function.
  • V811. Decreased performance. Excessive type casting: string -> char * -> string.
  • V812. Decreased performance. Ineffective use of the 'count' function. It can possibly be replaced by the call to the 'find' function.
  • V813. Decreased performance. The argument should probably be rendered as a constant pointer/reference.
  • V814. Decreased performance. The 'strlen' function was called multiple times inside the body of a loop.
  • V815. Decreased performance. Consider replacing the expression 'AA' with 'BB'.
  • V816. It is more efficient to catch exception by reference rather than by value.
  • V817. It is more efficient to search for 'X' character rather than a string.
  • V818. It is more efficient to use an initialization list rather than an assignment operator.
  • V819. Decreased performance. Memory is allocated and released multiple times inside the loop body.
  • V820. The variable is not used after copying. Copying can be replaced with move/swap for optimization.
  • V821. The variable can be constructed in a lower level scope.
  • V822. Decreased performance. A new object is created, while a reference to an object is expected.
  • V823. Decreased performance. Object may be created in-place in a container. Consider replacing methods: 'insert' -> 'emplace', 'push_*' -> 'emplace_*'.
  • V824. It is recommended to use the 'make_unique/make_shared' function to create smart pointers.
  • V825. Expression is equivalent to moving one unique pointer to another. Consider using 'std::move' instead.
  • V826. Consider replacing standard container with a different one.
  • V827. Maximum size of a vector is known at compile time. Consider pre-allocating it by calling reserve(N).
  • V828. Decreased performance. Moving an object in a return statement prevents copy elision.
  • V829. Lifetime of the heap-allocated variable is limited to the current function's scope. Consider allocating it on the stack instead.
  • V830. Decreased performance. Consider replacing the use of 'std::optional::value()' with either the '*' or '->' operator.

Диагностика 64-битных ошибок (Viva64, C++)

  • V101. Implicit assignment type conversion to memsize type.
  • V102. Usage of non memsize type for pointer arithmetic.
  • V103. Implicit type conversion from memsize type to 32-bit type.
  • V104. Implicit type conversion to memsize type in an arithmetic expression.
  • V105. N operand of '?:' operation: implicit type conversion to memsize type.
  • V106. Implicit type conversion N argument of function 'foo' to memsize type.
  • V107. Implicit type conversion N argument of function 'foo' to 32-bit type.
  • V108. Incorrect index type: 'foo[not a memsize-type]'. Use memsize type instead.
  • V109. Implicit type conversion of return value to memsize type.
  • V110. Implicit type conversion of return value from memsize type to 32-bit type.
  • V111. Call of function 'foo' with variable number of arguments. N argument has memsize type.
  • V112. Dangerous magic number N used.
  • V113. Implicit type conversion from memsize to double type or vice versa.
  • V114. Dangerous explicit type pointer conversion.
  • V115. Memsize type is used for throw.
  • V116. Memsize type is used for catch.
  • V117. Memsize type is used in the union.
  • V118. malloc() function accepts a dangerous expression in the capacity of an argument.
  • V119. More than one sizeof() operator is used in one expression.
  • V120. Member operator[] of object 'foo' is declared with 32-bit type argument, but is called with memsize type argument.
  • V121. Implicit conversion of the type of 'new' operator's argument to size_t type.
  • V122. Memsize type is used in the struct/class.
  • V123. Allocation of memory by the pattern "(X*)malloc(sizeof(Y))" where the sizes of X and Y types are not equal.
  • V124. Function 'Foo' writes/reads 'N' bytes. The alignment rules and type sizes have been changed. Consider reviewing this value.
  • V125. It is not advised to declare type 'T' as 32-bit type.
  • V126. Be advised that the size of the type 'long' varies between LLP64/LP64 data models.
  • V127. An overflow of the 32-bit variable is possible inside a long cycle which utilizes a memsize-type loop counter.
  • V128. A variable of the memsize type is read from a stream. Consider verifying the compatibility of 32 and 64 bit versions of the application in the context of a stored data.
  • V201. Explicit conversion from 32-bit integer type to memsize type.
  • V202. Explicit conversion from memsize type to 32-bit integer type.
  • V203. Explicit type conversion from memsize to double type or vice versa.
  • V204. Explicit conversion from 32-bit integer type to pointer type.
  • V205. Explicit conversion of pointer type to 32-bit integer type.
  • V206. Explicit conversion from 'void *' to 'int *'.
  • V207. A 32-bit variable is utilized as a reference to a pointer. A write outside the bounds of this variable may occur.
  • V220. Suspicious sequence of types castings: memsize -> 32-bit integer -> memsize.
  • V221. Suspicious sequence of types castings: pointer -> memsize -> 32-bit integer.
  • V301. Unexpected function overloading behavior. See N argument of function 'foo' in derived class 'derived' and base class 'base'.
  • V302. Member operator[] of 'foo' class has a 32-bit type argument. Use memsize-type here.
  • V303. The function is deprecated in the Win64 system. It is safer to use the 'foo' function.

Реализовано по запросам пользователей (C++)

  • V2001. Consider using the extended version of the 'foo' function here.
  • V2002. Consider using the 'Ptr' version of the 'foo' function here.
  • V2003. Explicit conversion from 'float/double' type to signed integer type.
  • V2004. Explicit conversion from 'float/double' type to unsigned integer type.
  • V2005. C-style explicit type casting is utilized. Consider using: static_cast/const_cast/reinterpret_cast.
  • V2006. Implicit type conversion from enum type to integer type.
  • V2007. This expression can be simplified. One of the operands in the operation equals NN. Probably it is a mistake.
  • V2008. Cyclomatic complexity: NN. Consider refactoring the 'Foo' function.
  • V2009. Consider passing the 'Foo' argument as a pointer/reference to const.
  • V2010. Handling of two different exception types is identical.
  • V2011. Consider inspecting signed and unsigned function arguments. See NN argument of function 'Foo' in derived class and base class.
  • V2012. Possibility of decreased performance. It is advised to pass arguments to std::unary_function/std::binary_function template as references.
  • V2013. Consider inspecting the correctness of handling the N argument in the 'Foo' function.
  • V2014. Don't use terminating functions in library code.
  • V2015. Identifiers that start with '__' or '_[A-Z]' are reserved.

Cтандарт MISRA

  • V2501. MISRA. Octal constants should not be used.
  • V2502. MISRA. The 'goto' statement should not be used.
  • V2503. MISRA. Implicitly specified enumeration constants should be unique – consider specifying non-unique constants explicitly.
  • V2504. MISRA. Size of an array is not specified.
  • V2505. MISRA. The 'goto' statement shouldn't jump to a label declared earlier.
  • V2506. MISRA. A function should have a single point of exit at the end.
  • V2507. MISRA. The body of a loop\conditional statement should be enclosed in braces.
  • V2508. MISRA. The function with the 'atof/atoi/atoll/atoll' name should not be used.
  • V2509. MISRA. The function with the 'abort/exit/getenv/system' name should not be used.
  • V2510. MISRA. The function with the 'qsort/bsearch' name should not be used.
  • V2511. MISRA. Memory allocation and deallocation functions should not be used.
  • V2512. MISRA. The macro with the 'setjmp' name and the function with the 'longjmp' name should not be used.
  • V2513. MISRA. Unbounded functions performing string operations should not be used.
  • V2514. MISRA. Unions should not be used.
  • V2515. MISRA. Declaration should contain no more than two levels of pointer nesting.
  • V2516. MISRA. The 'if' ... 'else if' construct should be terminated with an 'else' statement.
  • V2517. MISRA. Literal suffixes should not contain lowercase characters.
  • V2518. MISRA. The 'default' label should be either the first or the last label of a 'switch' statement.
  • V2519. MISRA. Every 'switch' statement should have a 'default' label, which, in addition to the terminating 'break' statement, should contain either a statement or a comment.
  • V2520. MISRA. Every switch-clause should be terminated by an unconditional 'break' or 'throw' statement.
  • V2521. MISRA. Only the first member of enumerator list should be explicitly initialized, unless all members are explicitly initialized.
  • V2522. MISRA. The 'switch' statement should have 'default' as the last label.
  • V2523. MISRA. All integer constants of unsigned type should have 'u' or 'U' suffix.
  • V2524. MISRA. A switch-label should only appear at the top level of the compound statement forming the body of a 'switch' statement.
  • V2525. MISRA. Every 'switch' statement should contain non-empty switch-clauses.
  • V2526. MISRA. The functions from time.h/ctime should not be used.
  • V2527. MISRA. A switch-expression should not have Boolean type. Consider using of 'if-else' construct.
  • V2528. MISRA. The comma operator should not be used.
  • V2529. MISRA. Any label should be declared in the same block as 'goto' statement or in any block enclosing it.
  • V2530. MISRA. Any loop should be terminated with no more than one 'break' or 'goto' statement.
  • V2531. MISRA. Expression of essential type 'foo' should not be explicitly cast to essential type 'bar'.
  • V2532. MISRA. String literal should not be assigned to object unless it has type of pointer to const-qualified char.
  • V2533. MISRA. C-style and functional notation casts should not be performed.
  • V2534. MISRA. The loop counter should not have floating-point type.
  • V2535. MISRA. Unreachable code should not be present in the project.
  • V2536. MISRA. Function should not contain labels not used by any 'goto' statements.
  • V2537. MISRA. Functions should not have unused parameters.
  • V2538. MISRA. The value of uninitialized variable should not be used.
  • V2539. MISRA. Class destructor should not exit with an exception.
  • V2540. MISRA. Arrays should not be partially initialized.
  • V2541. MISRA. Function should not be declared implicitly.
  • V2542. MISRA. Function with a non-void return type should return a value from all exit paths.
  • V2543. MISRA. Value of the essential character type should be used appropriately in the addition/subtraction operations.
  • V2544. MISRA. The values used in expressions should have appropriate essential types.
  • V2545. MISRA. Conversion between pointers of different object types should not be performed.
  • V2546. MISRA. Expression resulting from the macro expansion should be surrounded by parentheses.
  • V2547. MISRA. The return value of non-void function should be used.
  • V2548. MISRA. The address of an object with local scope should not be passed out of its scope.
  • V2549. MISRA. Pointer to FILE should not be dereferenced.
  • V2550. MISRA. Floating-point values should not be tested for equality or inequality.
  • V2551. MISRA. Variable should be declared in a scope that minimizes its visibility.
  • V2552. MISRA. Expressions with enum underlying type should have values corresponding to the enumerators of the enumeration.
  • V2553. MISRA. Unary minus operator should not be applied to an expression of the unsigned type.
  • V2554. MISRA. Expression containing increment (++) or decrement (--) should not have other side effects.
  • V2555. MISRA. Incorrect shifting expression.
  • V2556. MISRA. Use of a pointer to FILE when the associated stream has already been closed.
  • V2557. MISRA. Operand of sizeof() operator should not have other side effects.
  • V2558. MISRA. A pointer/reference parameter in a function should be declared as pointer/reference to const if the corresponding object was not modified.
  • V2559. MISRA. Subtraction, >, >=, <, <= should be applied only to pointers that address elements of the same array.
  • V2560. MISRA. There should be no user-defined variadic functions.
  • V2561. MISRA. The result of an assignment expression should not be used.
  • V2562. MISRA. Expressions with pointer type should not be used in the '+', '-', '+=' and '-=' operations.
  • V2563. MISRA. Array indexing should be the only form of pointer arithmetic and it should be applied only to objects defined as an array type.
  • V2564. MISRA. There should be no implicit integral-floating conversion.
  • V2565. MISRA. A function should not call itself either directly or indirectly.
  • V2566. MISRA. Constant expression evaluation should not result in an unsigned integer wrap-around.
  • V2567. MISRA. Cast should not remove 'const' / 'volatile' qualification from the type that is pointed to by a pointer or a reference.
  • V2568. MISRA. Both operands of an operator should be of the same type category.
  • V2569. MISRA. The 'operator &&', 'operator ||', 'operator ,' and the unary 'operator &' should not be overloaded.
  • V2570. MISRA. Operands of the logical '&&' or the '||' operators, the '!' operator should have 'bool' type.
  • V2571. MISRA. Conversions between pointers to objects and integer types should not be performed.
  • V2572. MISRA. Value of the expression should not be converted to the different essential type or the narrower essential type.
  • V2573. MISRA. Identifiers that start with '__' or '_[A-Z]' are reserved.

Проблемы при работе анализатора кода

  • V001. A code fragment from 'file' cannot be analyzed.
  • V002. Some diagnostic messages may contain incorrect line number.
  • V003. Unrecognized error found...
  • V004. Diagnostics from the 64-bit rule set are not entirely accurate without the appropriate 64-bit compiler. Consider utilizing 64-bit compiler if possible.
  • V005. Cannot determine active configuration for project. Please check projects and solution configurations.
  • V006. File cannot be processed. Analysis aborted by timeout.
  • V007. Deprecated CLR switch was detected. Incorrect diagnostics are possible.
  • V008. Unable to start the analysis on this file.
  • V009. To use free version of PVS-Studio, source code files are required to start with a special comment.
  • V010. Analysis of 'Makefile/Utility' type projects is not supported in this tool. Use direct analyzer integration or compiler monitoring instead.
  • V011. Presence of #line directives may cause some diagnostic messages to have incorrect file name and line number.
  • V012. Some warnings could have been disabled.
  • V051. Some of the references in project are missing or incorrect. The analysis results could be incomplete. Consider making the project fully compilable and building it before analysis.
  • V052. A critical error had occurred.

Как ввести лицензию PVS-Studio, и что делать дальше

Добро пожаловать на страницу PVS-Studio, где перечислены все способы активации лицензии. Скорее всего, вы только что её получили, чтобы попробовать анализатор, и на этой странице сможете узнать, как ею воспользоваться. Анализатор поддерживает анализ таких языков программирования, как C, C++, C# и Java, а запуск возможен на операционных системах Windows, Linux и macOS. В связи с этим, способы активации анализатора могут отличаться для разных проектов, поэтому перейдите в раздел, который Вам подходит и следуйте инструкции.

Важно. Все действия выполняются после установки анализатора. Вы можете скачать его на странице "Скачать PVS-Studio".

Windows: C, C++, C#

Microsoft Visual Studio

Перейдите в меню Visual Studio PVS-Studio > Options > PVS-Studio > Registration, чтобы ввести имя и номер лицензии:

https://import.viva64.com/docx/manual/EnterLicense_ru/image1.png

Compiler Monitoring UI

Перейдите в меню утилиты Tools > Options > Registration, чтобы ввести имя и номер лицензии:

https://import.viva64.com/docx/manual/EnterLicense_ru/image3.png

Command line analyzer for MSBuild projects

При использовании анализатора MSBuild проектов, когда нет возможности ввести лицензионную информацию через GUI (плагин для Visual Studio или Compiler Monitoring UI), можно воспользоваться самим анализатором в специальном режиме.

Строка запуска может выглядеть следующим образом (одной строкой):

PVS-Studio_Cmd.exe credentials 
--username NAME --serialNumber XXXX-XXXX-XXXX-XXXX

При таком запуске анализатор запишет лицензионную информацию в файл настроек с расположением по умолчанию. Если файла настроек не существует, он будет создан. Используя флаг --settings можно указать путь до файла настроек в нестандартном расположении.

Linux/macOS: C, C++, C#

После установки анализатора, активировать его можно с помощью следующей команды:

pvs-studio-analyzer credentials NAME XXXX-XXXX-XXXX-XXXX

Windows/Linux/macOS: C#, Java

IntelliJ IDEA / Rider

Перейдите в меню File > Settings > PVS-Studio > Registration, чтобы ввести имя и номер лицензии:

https://import.viva64.com/docx/manual/EnterLicense_ru/image5.png

Maven Plugin

После установки анализатора, активировать его можно с помощью следующей команды:

mvn pvsstudio:pvsCredentials "-Dpvsstudio.username=USR" "-Dpvsstudio.serial=KEY"

Gradle Plugin

После установки анализатора, активировать его можно с помощью следующей команды:

./gradlew pvsCredentials "-Ppvsstudio.username=USR" "-Ppvsstudio.serial=KEY"

Быстрый старт или что дальше?

Способы запуска анализатора приведены на соответствующих страницах:

Ознакомительный режим PVS-Studio

После загрузки дистрибутива PVS-Studio и запроса ключа для знакомства с инструментом, вы получаете полнофункциональную версию, которая работает неделю. В этой версии нет совершенно никаких ограничений – это абсолютно полноценная лицензия категории Team License.

Отличия Enterprise License от Team License представлены на этой странице. Для исследования возможностей Enterprise License просто напишите нам, и мы предоставим такую лицензию.

Если вам не хватило недели на знакомство с инструментом – просто запросите еще один ключ через ту же самую форму обратной связи, и мы пришлем его. Мы просим отправить повторный запрос для того, чтобы мы видели, что вы уже пробовали раньше работать с инструментом.

Системные требования анализатора PVS-Studio

Анализатор PVS-Studio работает на 64-битных системах Windows, Linux и macOS, и может анализировать код, предназначенный для 32-битных, 64-битных и встраиваемых ARM платформ.

PVS-Studio требует как минимум 1 GB оперативной памяти (рекомендуется 2 GB и больше) для каждого процессорного ядра, когда анализатор работает на многоядерной системе (чем больше ядер, тем быстрее работает анализ кода).

Поддерживаемые языки программирования и компиляторы

Список поддерживаемых анализатором языков программирования и компиляторов доступен здесь.

Windows

Поддерживаются Windows Vista, Windows Server 2008, Windows 7, Windows 8, Windows Server 2012, Windows 10, Windows Server 2016 and Windows Server 2019. PVS-Studio работает только под 64-битными версиями Windows.

Для работы PVS-Studio требуется .NET Framework версии 4.7.2 или выше (будет автоматически установлен при установке PVS-Studio, если подходящей версии нет в системе).

Плагин PVS-Studio может быть интегрирован в Microsoft Visual Studio 2019, 2017, 2015, 2013, 2012, 2010. Для анализа C и C++ кода для встраиваемых систем соответствующие компиляторы должны быть установлены в системе, на которой запускается анализатор.

Linux

PVS-Studio работает в 64-битных дистрибутивах Linux с ядром версий 2.6.x и выше. Для анализа C и C++ проектов для Linux, кросс-платформенных приложений или встраиваемых систем, соответствующие компиляторы должны быть установлены в системе.

macOS

PVS-Studio работает в macOS 10.13.2 High Sierra и выше. Для анализа C и C++ кода соответствующие компиляторы должны быть установлены в системе.

Java

PVS-Studio для Java работает на 64-битных системах Windows, Linux и macOS. Java 8 (64-битная) является минимальной версией для работы анализатора. Анализируемый проект может использовать любую версию Java.

История версий PVS-Studio

График количества диагностик в PVS-Studio

Анализатор PVS-Studio активно развивается. Например, наша команда постоянно совершенствует его интеграцию с такими системами как PlatformIO, Azure DevOps, Travis CI, CircleCI, GitLab CI/CD, Jenkins, SonarQube и т.д. Однако лучше всего развитие возможностей анализатора показывает график количества диагностик.

https://import.viva64.com/docx/manual/Release_history_ru/image1.png

Рисунок 1. Увеличение количества диагностик в PVS-Studio

Как видите, мы активно совершенствуем возможности анализатора по выявлению новых паттернов ошибок и заодно подталкиваем этим к развитию и другие инструменты :). Более подробная информация по нововведениям в различных версиях анализатора представлена ниже.

PVS-Studio 7.09 (27 августа 2020)

  • PVS-Studio включён в отчёт "Now Tech: Static Application Security Testing, Q3 2020" как SAST-специализированный инструмент. Использование методологии статического тестирования защищённости приложений (Static Application Security Testing, SAST) позволяет улучшить безопасность тестируемого приложения и смягчить влияние дефектов безопасности на его жизненный цикл. Forrester Research является одним из ведущих исследователей влияния развития инновационных технологий на бизнес. Отчёт об исследовании доступен для покупки подписчикам и клиентам Forrester Research.
  • В C# анализаторе PVS-Studio, для Visual Studio и Rider плагинов расширены возможности навигации по исходным файлам - для межпроцедурных срабатываний добавлена возможность перехода на потенциально опасные участки кода внутри методов, когда анализатор ругается на вызов такого метода.
  • Для C# анализатора PVS-Studio добавлена поддержка переопределения уровней значимости предупреждений в файлах настройки диагностик (.pvsconfig).
  • V012. Some warnings could have been disabled. Для C++ анализатора PVS-Studio добавлена возможность отображать в отчёте правила исключений из файлов настройки диагностик (.pvsconfig).
  • V826. Consider replacing standard container with a different one.
  • V827. Maximum size of a vector is known at compile time. Consider pre-allocating it by calling reserve(N).
  • V828. Decreased performance. Moving an object in a return statement prevents copy elision.
  • V829. Lifetime of the heap-allocated variable is limited to the current function's scope. Consider allocating it on the stack instead.
  • V1059. Macro name overrides a keyword/reserved name. This may lead to undefined behavior.
  • V1060. Passing 'BSTR ' to the 'SysAllocString' function may lead to incorrect object creation.
  • V1061. Extending 'std' or 'posix' namespace may result in undefined behavior.
  • V1062. Class defines a custom new or delete operator. The opposite operator must also be defined.
  • V1063. The modulo by 1 operation is meaningless. The result will always be zero.
  • V3154. The 'a % b' expression always evaluates to 0.
  • V3155. The expression is incorrect or it can be simplified.
  • V6082. Unsafe double-checked locking.
  • V6083. Serialization order of fields should be preserved during deserialization.
  • V6084. Suspicious return of an always empty collection.
  • V6085. An abnormality within similar comparisons. It is possible that a typo is present inside the expression.
  • V6086. Suspicious code formatting. 'else' keyword is probably missing.
  • V6087. InvalidClassException may occur during deserialization.
  • V6088. Result of this expression will be implicitly cast to 'Type'. Check if program logic handles it correctly.
  • V6089. It's possible that the line was commented out improperly, thus altering the program's operation logics.
  • V6090. Field 'A' is being used before it was initialized.
  • V6091. Suspicious getter/setter implementation. The 'A' field should probably be returned/assigned instead.
  • V6092. A resource is returned from try-with-resources statement. It will be closed before the method exits.

PVS-Studio 7.08 (18 июня 2020)

  • Анализатор PVS-Studio C# для .NET Framework и .NET Core проектов теперь доступен на операционных системах Linux и macOS.
  • Анализатор PVS-Studio C# теперь можно использовать вместе со средой разработки JetBrains Rider.
  • Анализатор PVS-Studio теперь можно легко попробовать на примерах C и C++ кода, без необходимости скачивать и устанавливать дистрибутив анализатора, с помощью интеграции с сервисом Compiler Explorer. Обратите внимание - сервис Compiler Explorer позволяет попробовать анализатор на небольшом, изолированном фрагменте кода или синтетическом примере. Для того, чтобы полноценно оценить возможности анализатора, скачайте и установите полную версию PVS-Studio.
  • Новый режим проверки списка файлов в утилите командной строки PVS-Studio_Cmd.exe на Windows теперь работает для C, C+ и C# файлов и умеет учитывать зависимости компиляции (исходных файлов от заголовочных файлов), что позволяет настраивать проверку pull и merge request'ов с помощью анализатора PVS-Studio.
  • Улучшена работа PVS-Studio C# при проверке Unity проектов - добавлены дополнительные аннотации для самых распространённых типов из библиотек Unity.
  • В утилиту для преобразования отчётов plog-converter (Linux, macOS) добавлена поддержка формата вывода для TeamCity.
  • В утилиту для автоматического оповещения разработчиков Blame Notifier добавлена поддержка системы контроля версий Perforce.
  • V824. It is recommended to use the 'make_unique/make_shared' function to create smart pointers.
  • V825. Expression is equivalent to moving one unique pointer to another. Consider using 'std::move' instead.
  • V1056. The predefined identifier '__func__' always contains the string 'operator()' inside function body of the overloaded 'operator()'.
  • V1057. Pseudo random sequence is the same at every program run. Consider assigning the seed to a value not known at compile-time.
  • V1058. Nonsensical comparison of two different functions' addresses.
  • V6078. Potential Java SE API compatibility issue.
  • V6079. Value of variable is checked after use. Potential logical error is present. Check lines: N1, N2.
  • V6080. Consider checking for misprints. It's possible that an assigned variable should be checked in the next condition.
  • V6081. Annotation that does not have 'RUNTIME' retention policy will not be accessible through Reflection API.

PVS-Studio 7.07 (16 апреля 2020)

  • В С++ анализаторе PVS-Studio добавлен синтаксический разбор концептов. Концепты - интерфейсное расширение шаблонов языка C++, введенное стандартом C++20. Исправлена ошибка V003, возникавшая при использовании концептов в проверяемом коде.
  • SonarQube плагин PVS-Studio теперь поддерживает работу в macOS.
  • В утилите для преобразования XML отчётов анализатора (PlogConverter) добавлена поддержка формата для Continuous Integration сервера TeamCity.
  • В command line анализаторе Visual Studio \ MSBuild проектов (PVS-Studio_Cmd.exe) добавлена возможность указывать и исключать из анализа отдельные проекты из командной строки, через флаги --selectProjects / --excludeProjects.
  • Исправлено зависание Visual Studio плагина PVS-Studio, вызванное повторной инициализацией плагина при открытии solution файла в IDE.
  • V1053. Calling the 'foo' virtual function in the constructor/destructor may lead to unexpected result at runtime.
  • V1054. Object slicing. Derived class object was copied to the base class object.
  • V1055. The 'sizeof' expression returns the size of the container type, not the number of elements. Consider using the 'size()' function.
  • V2573. MISRA. Identifiers that start with '__' or '_[A-Z]' are reserved.

PVS-Studio 7.06 (27 февраля 2020)

  • PVS-Studio теперь можно использовать совместно с кросс-платформенной IDE для embedded разработки PlatformIO. Подробнее про настройку PVS-Studio в PlatformIO можно почитать здесь.
  • Оптимизировано выделение памяти C# анализатором PVS-Studio, что может давать ускорение анализа при проверке крупных проектов.
  • В C# анализаторе PVS-Studio добавлены опции --excludeDefines / --appendDefines, позволяющие исключать/добавлять символы препроцессора, которые будут использоваться при анализе.
  • C# анализатор PVS-Studio теперь понимает Unity-специфичные проверки переменных на null через их неявное преобразование к типу bool.
  • V823. Decreased performance. Object may be created in-place in a container. Consider replacing methods: 'insert' -> 'emplace', 'push_*' -> 'emplace_*'.
  • V1050. The uninitialized class member is used when initializing the base class.
  • V1051. Consider checking for misprints. It's possible that an assigned variable should be checked in the next condition.
  • V1052. Declaring virtual methods in a class marked as 'final' is pointless.
  • V2562. MISRA. Expressions with pointer type should not be used in the '+', '-', '+=' and '-=' operations.
  • V2563. MISRA. Array indexing should be the only form of pointer arithmetic and it should be applied only to objects defined as an array type.
  • V2564. MISRA. There should be no implicit integral-floating conversion.
  • V2565. MISRA. A function should not call itself either directly or indirectly.
  • V2566. MISRA. Constant expression evaluation should not result in an unsigned integer wrap-around.
  • V2567. MISRA. Cast should not remove 'const' / 'volatile' qualification from the type that is pointed to by a pointer or a reference.
  • V2568. MISRA. Both operands of an operator should be of the same type category.
  • V2569. MISRA. The 'operator &&', 'operator ||', 'operator ,' and the unary 'operator &' should not be overloaded.
  • V2570. MISRA. Operands of the logical '&&' or the '||' operators, the '!' operator should have 'bool' type.
  • V2571. MISRA. Conversions between pointers to objects and integer types should not be performed.
  • V2572. MISRA. Value of the expression should not be converted to the different essential type or the narrower essential type.
  • V3150. Loop break conditions do not depend on the number of iterations.
  • V3151. Potential division by zero. Variable was used as a divisor before it was compared to zero. Check lines: N1, N2.
  • V3152. Potential division by zero. Variable was compared to zero before it was used as a divisor. Check lines: N1, N2.
  • V3153. Dereferencing the result of null-conditional access operator can lead to NullReferenceException. Consider removing parentheses around null-conditional access expression.
  • V6077. Label is present inside a switch(). It is possible that these are misprints and 'default:' operator should be used instead.

PVS-Studio 7.05 (10 декабря 2019)

  • Утилита для оповещения разработчиков о результатах анализа Blame Notifier теперь доступна на всех поддерживаемых анализатором платформах (Windows, Linux, macOS). Blame Notifier использует информацию из системы контроля версий (SVN, Git, Mercurial) для определения человека, написавшего код, на который анализатор выдаёт сообщение.
  • PVS-Studio теперь можно установить с помощью менеджера пакетов Chocolatey.
  • Добавлена поддержка проверки проектов .NET Core 3 и 3.1 для C# анализатора.
  • В Windows версии анализатора появилась возможность задавать исключённые из анализа директории на уровне конкретного Visual Studio проекта или solution'а с помощью .pvsconfig файлов.
  • Оптимизирован расход памяти C# анализатором PVS-Studio при проверке крупных проектов.
  • V822. Decreased performance. A new object is created, while a reference to an object is expected.
  • V1044. Loop break conditions do not depend on the number of iterations.
  • V1045. The DllMain function throws an exception. Consider wrapping the throw operator in a try..catch block.
  • V1046. Unsafe usage of the 'bool' and integer types together in the operation '&='.
  • V1047. Lifetime of the lambda is greater than lifetime of the local variable captured by reference.
  • V1048. Variable 'foo' was assigned the same value.
  • V1049. The 'foo' include guard is already defined in the 'bar1.h' header. The 'bar2.h' header will be excluded from compilation.
  • V2558. MISRA. A pointer/reference parameter in a function should be declared as pointer/reference to const if the corresponding object was not modified.
  • V2559. MISRA. Subtraction, >, >=, <, <= should be applied only to pointers that address elements of the same array.
  • V2560. MISRA. There should be no user-defined variadic functions.
  • V2561. MISRA. The result of an assignment expression should not be used.
  • V3146. Possible null dereference. A method can return default null value.
  • V3147. Non-atomic modification of volatile variable.
  • V3148. Casting potential 'null' value to a value type can lead to NullReferenceException.
  • V3149. Dereferencing the result of 'as' operator can lead to NullReferenceException.
  • V6072. Two similar code fragments were found. Perhaps, this is a typo and 'X' variable should be used instead of 'Y'.
  • V6073. It is not recommended to return null or throw exceptions from 'toString' / 'clone' methods.
  • V6074. Non-atomic modification of volatile variable.
  • V6075. The signature of method 'X' does not conform to serialization requirements.
  • V6076. Recurrent serialization will use cached object state from first serialization.

PVS-Studio 7.04 (4 сентября 2019)

  • Добавлена поддержка IntelliJ IDEA версии 192 в PVS-Studio плагине для этой IDE.
  • В PVS-Studio плагины для Visual Studio добавлена возможность автоматической загрузки логов анализа при проверке Unreal Engine проектов.
  • Добавлена возможность проверки C# проектов под .NET Core 3 Preview.
  • В C# анализаторе добавлено вычисление возвращаемых значений async методов, а также get и set методов у свойств.
  • В утилите для отслеживания запусков компиляторов на Windows добавлена возможность отслеживать только дочерние процессы у заданного процесса.
  • В утилите для отслеживания запусков компиляторов на Linux добавлен режим работы с игнорированием ccache кэша.
  • Плагин для отображения результатов анализа PVS-Studio в Jenkins теперь можно также использовать на Linux\macOS хостах (раньше он был доступен только для Windows)
  • Добавлена поддержка SonarQube 7.9 LTS в плагине PVS-Studio для SonarQube.
  • V1040. Possible typo in the spelling of a pre-defined macro name.
  • V1041. Class member is initialized with dangling reference.
  • V1042. This file is marked with copyleft license, which requires you to open the derived source code.
  • V1043. A global object variable is declared in the header. Multiple copies of it will be created in all translation units that include this header file.
  • V2551. MISRA. Variable should be declared in a scope that minimizes its visibility.
  • V2552. MISRA. Expressions with enum underlying type should have values corresponding to the enumerators of the enumeration.
  • V2553. MISRA. Unary minus operator should not be applied to an expression of the unsigned type.
  • V2554. MISRA. Expression containing increment (++) or decrement (--) should not have other side effects.
  • V2555. MISRA. Incorrect shifting expression.
  • V2556. MISRA. Use of a pointer to FILE when the associated stream has already been closed.
  • V2557. MISRA. Operand of sizeof() operator should not have other side effects.
  • V3140. Property accessors use different backing fields.
  • V3141. Expression under 'throw' is a potential null, which can lead to NullReferenceException.
  • V3142. Unreachable code detected. It is possible that an error is present.
  • V3143. The 'value' parameter is rewritten inside a property setter, and is not used after that.
  • V3144. This file is marked with copyleft license, which requires you to open the derived source code.
  • V3145. Unsafe dereference of a WeakReference target. The object could have been garbage collected before the 'Target' property was accessed.
  • V6068. Suspicious use of BigDecimal class.
  • V6069. Unsigned right shift assignment of negative 'byte' / 'short' value.
  • V6070. Unsafe synchronization on an object.
  • V6071. This file is marked with copyleft license, which requires you to open the derived source code.

PVS-Studio 7.03 (25 июня 2019)

  • В документации анализатора PVS-Studio теперь доступен раздел по использованию анализатора в контейнерах с помощью Docker.
  • Добавлена поддержка проверки проектов для QNX Momentics, компилятора QCC.
  • V1038. It's odd that a char or string literal is added to a pointer.
  • V1039. Character escape is used in multicharacter literal. This causes implementation-defined behavior.
  • V2543. MISRA. Value of the essential character type should be used appropriately in the addition/subtraction operations.
  • V2544. MISRA. Values of the essential appropriate types should be used at expressions.
  • V2545. MISRA. Conversion between pointers of different object types should not be performed.
  • V2546. MISRA. Expression resulting from the macro expansion should be surrounded by parentheses.
  • V2547. MISRA. The return value of non-void function should be used.
  • V2548. MISRA. The address of an object with local scope should not be passed out of its scope.
  • V2549. MISRA. Pointer to FILE should not be dereferenced.
  • V2550. MISRA. Floating-point values should not be tested for equality or inequality.
  • V3138. String literal contains potential interpolated expression.
  • V3139. Two or more case-branches perform the same actions.
  • V6067. Two or more case-branches perform the same actions.

PVS-Studio 7.02 (25 апреля 2019)

  • В PVS-Studio появилась поддержка Visual Studio 2019. Visual C++, .NET Framework и .NET Core C# проекты Visual Studio 2019 можно проверять как из самой IDE, так и из командной строки с помощью утилиты PVS-Studio_Cmd.exe.
  • Добавлена поддержка нового синтаксиса из C# 8.0 в PVS-Studio C# анализатор.
  • PVS-Studio C# теперь может видеть потенциальные разыменования нулевых ссылок (диагностика V3080) внутри тел методов, когда значение потенциального null'а передаётся в качестве аргумента метода.
  • Плагин PVS-Studio Java анализатора для IntelliJ IDEA теперь доступен в официальном репозитории плагинов JetBrains. Также плагин для IDEA теперь можно установить с помощью нашего Windows инсталлятора.
  • В PVS-Studio Java плагины для IDEA, Maven и Gradle добавлен режим массового подавления предупреждений, который можно использовать для скрытия предупреждений на старом коде при внедрении анализатора в процесс разработки.
  • Исправлена работа Compiler Monitoring на Windows при отслеживании сборки, запущенной из под Keil uVision в случае, когда имя пользователя в системе содержит нелатинские символы.
  • V1037. Two or more case-branches perform the same actions.
  • V2530. MISRA. The loop should be terminated with no more than one 'break' or 'goto' statement.
  • V2531. MISRA. Expression of the essential 'foo' type should not be cast to the essential 'bar' type.
  • V2532. MISRA. String literal should not be assigned to object unless it has type of pointer to const-qualified char.
  • V2533. MISRA. C-style and functional notation casts should not be performed.
  • V2534. MISRA. The loop counter should not have floating-point type.
  • V2535. MISRA. Unreachable code should not be present in the project.
  • V2536. MISRA. Function should not contain labels not used by any 'goto' statements.
  • V2537. MISRA. Functions should not have unused parameters.
  • V2538. MISRA. The value of uninitialized variable should not be used.
  • V2539. MISRA. Class destructor should not exit with an exception.
  • V2540. MISRA. Arrays should not be partially initialized.
  • V2541. MISRA. Function should not be declared implicitly.
  • V2542. MISRA. Function with a non-void return type should return a value from all exit paths.

PVS-Studio 7.01 (13 марта 2019)

  • Ограничений количества переходов по сообщениям анализатора в Visual Studio в trial больше нет! В PVS-Studio для Windows теперь используется общая с остальными платформами trial модель - вы можете получить полнофункциональную лицензию, заполнив форму на странице загрузки анализатора.
  • PVS-Studio C# диагностика V3080 (разыменование нулевой ссылки) теперь умеет находить потенциальные разыменования ссылок, которые могут принимать значение null в одной из веток выполнения. Улучшен межпроцедурный анализ.
  • В Visual Studio плагине PVS-Studio добавлена возможность при работе с проектами, хранящимися в TFVC (Team Foundation Version Control), делать автоматический checkout suppress файлов (режим включается в Options... > Specific Analzyer Settings).
  • V1036. Potentially unsafe double-checked locking.
  • V2529. MISRA. Any label should be declared in the same block as 'goto' statement or in any block enclosing it.

PVS-Studio 7.00 (16 января 2019)

  • В PVS-Studio версии 7.00 появился статический анализатор для Java. Подробнее обо всех нововведениях в PVS-Studio 7.00 можно почитать в нашем блоге.
  • Плагин PVS-Studio для SonarQube обновлён для поддержки последней версии SonarQube 7.4. Минимальная версия SonarQube, поддерживаемая последней версией PVS-Studio плагина, увеличена до LTS версии SonarQube 6.7.
  • V2526. MISRA. The function with the 'clock/time/difftime/ctime/ asctime/gmtime/localtime/mktime' name should not be used.
  • V2527. MISRA. A switch-expression should not have Boolean type. Consider using of 'if-else' construct.
  • V2528. MISRA. The comma operator should not be used.
  • V6001. There are identical sub-expressions to the left and to the right of the 'foo' operator.
  • V6002. The switch statement does not cover all values of the enum.
  • V6003. The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence.
  • V6004. The 'then' statement is equivalent to the 'else' statement.
  • V6005. The 'x' variable is assigned to itself.
  • V6006. The object was created but it is not being used. The 'throw' keyword could be missing.
  • V6007. Expression is always true/false.
  • V6008. Potential null dereference.
  • V6009. Function receives an odd argument.
  • V6010. The return value of function 'Foo' is required to be utilized.
  • V6011. The expression contains a suspicious mix of integer and real types
  • V6012. The '?:' operator, regardless of its conditional expression, always returns one and the same value.
  • V6013. Comparison of arrays, strings, collections by reference. Possibly an equality comparison was intended.
  • V6014. It's odd that this method always returns one and the same value of NN.
  • V6015. Consider inspecting the expression. Probably the '!='/'-='/'+=' should be used here.
  • V6016. Suspicious access to element by a constant index inside a loop.
  • V6017. The 'X' counter is not used inside a nested loop. Consider inspecting usage of 'Y' counter.
  • V6018. Constant expression in switch statement.
  • V6019. Unreachable code detected. It is possible that an error is present.
  • V6020. Division or mod division by zero.
  • V6021. The value is assigned to the 'x' variable but is not used.
  • V6022. Parameter is not used inside method's body.
  • V6023. Parameter 'A' is always rewritten in method body before being used.
  • V6024. The 'continue' operator will terminate 'do { ... } while (false)' loop because the condition is always false.
  • V6025. Possibly index is out of bound.
  • V6026. This value is already assigned to the 'b' variable.
  • V6027. Variables are initialized through the call to the same function. It's probably an error or un-optimized code.
  • V6028. Identical expressions to the left and to the right of compound assignment.
  • V6029. Possible incorrect order of arguments passed to method.
  • V6030. The function located to the right of the '|' and '&' operators will be called regardless of the value of the left operand. Consider using '||' and '&&' instead.
  • V6031. The variable 'X' is being used for this loop and for the outer loop.
  • V6032. It is odd that the body of 'Foo_1' function is fully equivalent to the body of 'Foo_2' function.
  • V6033. An item with the same key has already been added.
  • V6034. Shift by N bits is inconsistent with the size of type.
  • V6035. Double negation is present in the expression: !!x.
  • V6036. The value from the uninitialized optional is used.
  • V6037. An unconditional 'break/continue/return/goto' within a loop.
  • V6038. Comparison with 'double.NaN' is meaningless. Use 'double.isNaN()' method instead.
  • V6039. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless.
  • V6040. The code's operational logic does not correspond with its formatting.
  • V6041. Suspicious assignment inside the conditional expression of 'if/while/do...while' statement.
  • V6042. The expression is checked for compatibility with type 'A', but is cast to type 'B'.
  • V6043. Consider inspecting the 'for' operator. Initial and final values of the iterator are the same.
  • V6044. Postfix increment/decrement is senseless because this variable is overwritten.
  • V6045. Suspicious subexpression in a sequence of similar comparisons.
  • V6046. Incorrect format. Consider checking the N format items of the 'Foo' function.
  • V6047. It is possible that this 'else' branch must apply to the previous 'if' statement.
  • V6048. This expression can be simplified. One of the operands in the operation equals NN. Probably it is a mistake.
  • V6049. Classes that define 'equals' method must also define 'hashCode' method.
  • V6050. Class initialization cycle is present.
  • V6051. Use of jump statements in 'finally' block can lead to the loss of unhandled exceptions.
  • V6052. Calling an overridden method in parent-class constructor may lead to use of uninitialized data.
  • V6053. Collection is modified while iteration is in progress. ConcurrentModificationException may occur.
  • V6054. Classes should not be compared by their name.
  • V6055. Expression inside assert statement can change object's state.
  • V6056. Implementation of 'compareTo' overloads the method from a base class. Possibly, an override was intended.
  • V6057. Consider inspecting this expression. The expression is excessive or contains a misprint.
  • V6058. The 'X' function receives objects of incompatible types.
  • V6059. Odd use of special character in regular expression. Possibly, it was intended to be escaped.
  • V6060. The reference was used before it was verified against null.
  • V6061. The used constant value is represented by an octal form.
  • V6062. Possible infinite recursion.
  • V6063. Odd semicolon ';' after 'if/foreach' operator.
  • V6064. Suspicious invocation of Thread.run().
  • V6065. A non-serializable class should not be serialized.
  • V6066. Passing objects of incompatible types to the method of collection.

Старая история версий

Старую историю версий для прошлых релизов смотрите здесь.

Старая история версий PVS-Studio (до версии 7.00)

Новую историю версий смотрите здесь.

PVS-Studio 6.27 (3 декабря 2018)

  • Исходный код утилит для преобразования отчётов анализатора (plog converter) теперь доступен на нашем GitHub портале: https://github.com/viva64
  • PVS-Studio теперь поддерживает стандарты написания кода MISRA C и MISRA C++. Список поддерживаемых диагностик будет постепенно расширяться в следующих версиях анализатора.
  • V2501. MISRA. Octal constants should not be used.
  • V2502. MISRA. The 'goto' statement should not be used.
  • V2503. MISRA. Implicitly specified enumeration constants should be unique – consider specifying non-unique constants explicitly.
  • V2504. MISRA. Size of an array is not specified.
  • V2505. MISRA. The 'goto' statement shouldn't jump to a label declared earlier.
  • V2506. MISRA. A function should have a single point of exit at the end.
  • V2507. MISRA. The body of a loop\conditional statement should be enclosed in braces.
  • V2508. MISRA. The function with the 'atof/atoi/atoll/atoll' name should not be used.
  • V2509. MISRA. The function with the 'abort/exit/getenv/system' name should not be used.
  • V2510. MISRA. The function with the 'qsort/bsearch' name should not be used.
  • V2511. MISRA. Memory allocation and deallocation functions should not be used.
  • V2512. MISRA. The macro with the 'setjmp' name and the function with the 'longjmp' name should not be used.
  • V2513. MISRA. Unbounded functions performing string operations should not be used.
  • V2514. MISRA. Unions should not be used.
  • V2515. MISRA. Declaration should contain no more than two levels of pointer nesting.
  • V2516. MISRA. The 'if' ... 'else if' construct shall be terminated with an 'else' statement.
  • V2517. MISRA. Literal suffixes should not contain lowercase characters.
  • V2518. MISRA. The 'default' label should be either the first or the last label of a 'switch' statement.
  • V2519. MISRA. The 'default' label is missing in 'switch' statement.
  • V2520. MISRA. Every switch-clause should be terminated by an unconditional 'break' or 'throw' statement.
  • V2521. MISRA. Only the first member of enumerator list should be explicitly initialized, unless all members are explicitly initialized.
  • V2522. MISRA. The 'switch' statement should have 'default' as the last label.
  • V2523. MISRA. All integer constants of unsigned type should have 'u' or 'U' suffix.
  • V2524. MISRA. A switch-label should only appear at the top level of the compound statement forming the body of a 'switch' statement.
  • V2525. MISRA. Every 'switch' statement should contain non-empty switch-clauses.

PVS-Studio 6.26 (18 октября 2018)

  • Добавлена поддержка проверки проектов для GNU Arm Embedded Toolchain, Arm Embedded GCC compiler.
  • Добавлена возможность использовать pvsconfig файлы с CLMonitor/Standalone на Windows.
  • При анализе проектов для Visual C++ компилятора (cl.exe, проекты vcxproj для Visual Studio/Standalone), в отчёте анализатора теперь сохраняется регистр в путях до проверенных файлов.
  • Добавлен режим инкрементального анализа для pvs-studio-analzyer/CMake модуля. PVS-Studio CMake модуль можно теперь использовать на Windows для проектов, использующих компилятор Visual C++ (cl.exe).
  • Добавлена поддержка инкрементального анализа для .NET Core/.NET Standard Visual Studio проектов.
  • Добавлена возможность проверять проекты для сборочной системы WAF.
  • V1021. The variable is assigned the same value on several loop iterations.
  • V1022. An exception was thrown by pointer. Consider throwing it by value instead.
  • V1023. A pointer without owner is added to the container by the 'emplace_back' method. A memory leak will occur in case of an exception.
  • V1024. The stream is checked for EOF before reading from it, but is not checked after reading. Potential use of invalid data.
  • V1025. Rather than creating 'std::unique_lock' to lock on the mutex, a new variable with default value is created.
  • V1026. The variable is incremented in the loop. Undefined behavior will occur in case of signed integer overflow.
  • V1027. Pointer to an object of the class is cast to unrelated class.
  • V1028. Possible overflow. Consider casting operands, not the result.
  • V1029. Numeric Truncation Error. Return value of function is written to N-bit variable.
  • V1030. The variable is used after it was moved.
  • V1031. Function is not declared. The passing of data to or from this function may be affected.
  • V1032. Pointer is cast to a more strictly aligned pointer type.
  • V1033. Variable is declared as auto in C. Its default type is int.
  • V1034. Do not use real-type variables as loop counters.
  • V1035. Only values that are returned from fgetpos() can be used as arguments to fsetpos().
  • V2014. Don't use terminating functions in library code.

PVS-Studio 6.25 (20 августа 2018)

  • Добавлена возможность в Visual Studio дабавлять в solution общий для всех проектов suppress файл.
  • Для поддержки последних типов Visual Studio C++/C# проектов и новых возможностей языка C#, обновлены версии библиотек Roslyn и MSBuild.
  • Улучшена проверка Multi-target C# проектов.
  • В CMake модуле добавлена поддержка generator expressions и неявных зависимостей проверяемых файлов.
  • У нас на сайте теперь можно посмотреть, как использовать PVS-Studio в рамках методологии безопасной разработки (SDL, Security Development Lifecycle) как SAST (Static Application Security Testing) инструмент. На этой странице есть отображение диагностических правил анализатора в формате CWE (Common Weakness Enumeration) и стандарте написания кода SEI CERT, прогресс по поддержке в PVS-Studio стандартов MISRA.

PVS-Studio 6.24 (14 июня 2018)

  • Добавлена поддержка Texas Instruments Code Composer Studio, ARM компилятора для Windows\Linux
  • Добавлена возможность сохранять дамп мониторинга и запускать анализ из этого дампа на Windows. Это позволяет перезапускать анализ без необходимости каждый раз пересобирать проект заново.
  • Добавлен режим проверки отдельных файлов в cmd версии анализатора для Visual Studio проектов на Windows
  • V1013. Suspicious subexpression in a sequence of similar comparisons.
  • V1014. Structures with members of real type are compared byte-wise.
  • V1015. Suspicious simultaneous use of bitwise and logical operators.
  • V1016. The value is out of range of enum values. This causes unspecified or undefined behavior.
  • V1017. Variable of the 'string_view' type references a temporary object which will be removed after evaluation of an expression.
  • V1018. Usage of a suspicious mutex wrapper. It is probably unused, uninitialized, or already locked.
  • V1019. Compound assignment expression is used inside condition.
  • V1020. Function exited without performing epilogue actions. It is possible that there is an error.

PVS-Studio 6.23 (28 марта 2018)

  • Мы выпустили PVS-Studio для macOS! Теперь проверять C и C++ код с помощью PVS-Studio можно не только в Windows/Linux, но и в macOS. Анализатор доступен в виде pkg-инсталлятора, tgz-архива и через менеджер пакетов Homebrew. Вы можете ознакомиться с документацией по работе с macOS-версией PVS-Studio здесь.
  • V011. Presence of #line directives may cause some diagnostic messages to have incorrect file name and line number.
  • V1011. Function execution could be deferred. Consider specifying execution policy explicitly.
  • V1012. The expression is always false. Overflow check is incorrect.

PVS-Studio 6.22 (28 февраля 2018)

  • Добавлена поддержка проверки проектов, использующих компиляторы Keil MDK ARM Compiler 5 и ARM Compiler 6.
  • Добавлена поддержка проверки проектов, использующих компилятор IAR C/C++ Compiler for ARM.
  • V1008. Consider inspecting the 'for' operator. No more than one iteration of the loop will be performed.
  • V1009. Check the array initialization. Only the first element is initialized explicitly.
  • V1010. Unchecked tainted data is used in expression.

PVS-Studio 6.21 (15 января 2018)

  • Добавлена поддержка CWE (Common Weakness Enumeration) для C/C++/C# анализаторов.
  • HTML отчёт с навигацией по коду можно теперь сохранять из Visual Studio плагинов и Standalone утилиты.
  • Добавлена поддержка проверки WDK (Windows Driver Kit) проектов для Visual Studio 2017
  • Плагин PVS-Studio для SonarQube обновлён для использования с последней LTS версией 6.7.
  • V1007. The value from the uninitialized optional is used. Probably it is a mistake.

PVS-Studio 6.20 (1 декабря 2017)

  • Вы можете сохранить результаты анализа в формате HTML с полной навигацией по коду.
  • Добавлен режим NoNoise для отключения сообщений Low (третьего) уровня достоверности.

PVS-Studio 6.19 (14 ноября 2017)

  • Добавлена возможность подавлять сообщения из XML отчёта (.plog) из командной строки в версии для Windows.
  • Улучшены скорость и стабильности работы подавления сообщений и инкрементального анализа из Visual Studio плагинов при работе с очень большими (тысячи проектов) решениями.
  • V1004. The pointer was used unsafely after it was verified against nullptr.
  • V1005. The resource was acquired using 'X' function but was released using incompatible 'Y' function.
  • V1006. Several shared_ptr objects are initialized by the same pointer. A double memory deallocation will occur.

PVS-Studio 6.18 (26 сентября 2017)

  • В Linux-версии появилось расположение по умолчанию для файла лицензии.
  • В Linux-версии появился механизм ввода лицензии (credentials).
  • В Linux-версии появился отчет анализатора в HTML формате.
  • В Windows-версии добавлена поддержка ASP.Net Core проектов.
  • В Windows-версии улучшено масштабирование элементов интерфейса на разных DPI.
  • В Windows-версии оптимизирована работа окна сообщений PVS-Studio при работе с большими отчётами, при выполнении сортировки по столбцам, при большом количестве выделенных сообщений.
  • В плагине для Visual Studio удалена функциональность "Send to External Tool".
  • В плагине для Visual Studio существенно изменены диалоги продления триала.
  • V1002. A class, containing pointers, constructor and destructor, is copied by the automatically generated operator= or copy constructor.
  • V1003. The macro is a dangerous, or the expression is suspicious.

PVS-Studio 6.17 (30 августа 2017)

  • Поддержка обновления Visual Studio 2017 15.3.
  • Добавлена возможность сохранять отчёт работы анализатора из Visual Studio плагина и Standalone в форматах txt\csv\html, без необходимости вручную вызывать PlogConverter.
  • Лицензия и файл настроек теперь сохраняются в кодировке UTF-8.
  • Добавлен список недавно открытых логов в меню Visual Studio плагина.
  • Инкрементальный анализ в PVS-Studio_Cmd.exe - добавлена опция "AppendScan". Подробности в описании утилиты PVS-Studio_Cmd здесь.
  • Добавлен плагин для отображения результатов анализа в системе непрерывной интеграции Jenkins (на Windows).
  • Реализована версия плагина для системы непрерывного контроля качества SonarQube для Linux.
  • Добавлена поддержка необработанного вывода C++ анализатора для утилиты PlogConverter.
  • V821. The variable can be constructed in a lower level scope.
  • V1001. The variable is assigned but is not used until the end of the function.
  • V3135. The initial value of the index in the nested loop equals 'i'. Consider using 'i + 1' instead.
  • V3136. Constant expression in switch statement.
  • V3137. The variable is assigned but is not used until the end of the function.

PVS-Studio 6.16 (28 июня 2017)

  • Основанные на clang toolset'ы поддержаны для Visual Studio 2015/2017.
  • Директория решения теперь может использоваться как Source Tree Root в Visual Studio.
  • V788. Review captured variable in lambda expression.
  • V789. Iterators for the container, used in the range-based for loop, become invalid upon a function call.
  • V790. It is odd that the assignment operator takes an object by a non-constant reference and returns this object.
  • V791. The initial value of the index in the nested loop equals 'i'. Consider using 'i + 1' instead.
  • V792. The function located to the right of the '|' and '&' operators will be called regardless of the value of the left operand. Consider using '||' and '&&' instead.
  • V793. It is odd that the result of the statement is a part of the condition. Perhaps, this statement should have been compared with something else.
  • V794. The copy operator should be protected from the case of this == &src.
  • V795. Note that the size of the 'time_t' type is not 64 bits. After the year 2038, the program will work incorrectly.
  • V796. A 'break' statement is probably missing in a 'switch' statement.
  • V797. The function is used as if it returned a bool type. The return value of the function should probably be compared with std::string::npos.
  • V798. The size of the dynamic array can be less than the number of elements in the initializer.
  • V799. The variable is not used after memory has been allocated for it. Consider checking the use of this variable.
  • V818. It is more efficient to use an initialization list rather than an assignment operator.
  • V819. Decreased performance. Memory is allocated and released multiple times inside the loop body.
  • V820. The variable is not used after copying. Copying can be replaced with move/swap for optimization.

PVS-Studio 6.15 (27 апреля 2017)

  • Улучшена поддержка Visual Studio 2017.
  • Исправлена ошибка с некоторыми .pch файлами.
  • V782. It is pointless to compute the distance between the elements of different arrays.
  • V783. Dereferencing of invalid iterator 'X' might take place.
  • V784. The size of the bit mask is less than the size of the first operand. This will cause the loss of the higher bits.
  • V785. Constant expression in switch statement.
  • V786. Assigning the value C to the X variable looks suspicious. The value range of the variable: [A, B].
  • V787. A wrong variable is probably used as an index in the for statement.

PVS-Studio 6.14 (17 марта 2017)

  • Добавлена поддержка Visual Studio 2017.
  • Добавлена поддержка Roslyn 2.0 / C# 7.0 в C# анализаторе PVS-Studio.
  • Добавлена подсветка строк при просмотре сообщений анализатора в Visual Studio плагинах \ Standalone версии.
  • Исправлена проблема проверки C++ проектов, которая могла возникнуть при запуске анализа на системе без установленной Visual Studio 2015 \ MSBuild 14.
  • V780. The object of non-passive (non-PDS) type cannot be used with the function.
  • V781. The value of the variable is checked after it was used. Perhaps there is a mistake in program logic. Check lines: N1, N2.
  • V3131. The expression is checked for compatibility with type 'A' but is cast to type 'B'.
  • V3132. A terminal null is present inside a string. '\0xNN' character sequence was encountered. Probably meant: '\xNN'.
  • V3133. Postfix increment/decrement is meaningless because this variable is overwritten.
  • V3134. Shift by N bits is greater than the size of type.

PVS-Studio 6.13 (27 января 2017)

  • Добавлен режим инкрементального анализа для cmd версии анализатора (PVS-Studio_Cmd.exe). Подробности в документации.
  • V779. Unreachable code detected. It is possible that an error is present.
  • V3128. The field (property) is used before it is initialized in constructor.
  • V3129. The value of the captured variable will be overwritten on the next iteration of the loop in each instance of anonymous function that captures it.
  • V3130. Priority of the '&&' operator is higher than that of the '||' operator. Possible missing parentheses.

PVS-Studio 6.12 (22 декабря 2016)

  • V773. The function was exited without releasing the pointer. A memory leak is possible.
  • V774. The pointer was used after the memory was released.
  • V775. It is odd that the BSTR data type is compared using a relational operator.
  • V776. Potentially infinite loop. The variable in the loop exit condition does not change its value between iterations.
  • V777. Dangerous widening type conversion from an array of derived-class objects to a base-class pointer.
  • V778. Two similar code fragments were found. Perhaps, this is a typo and 'X' variable should be used instead of 'Y'.
  • V3123. Perhaps the '??' operator works differently from what was expected. Its priority is lower than that of other operators in its left part.
  • V3124. Appending an element and checking for key uniqueness is performed on two different variables.
  • V3125. The object was used after it was verified against null. Check lines: N1, N2.
  • V3126. Type implementing IEquatable<T> interface does not override 'GetHashCode' method.

PVS-Studio 6.11 (29 ноября 2016)

  • V771. The '?:' operator uses constants from different enums.
  • V772. Calling the 'delete' operator for a void pointer will cause undefined behavior.
  • V817. It is more efficient to search for 'X' character rather than a string.
  • V3119. Calling a virtual (overridden) event may lead to unpredictable behavior. Consider implementing event accessors explicitly or use 'sealed' keyword.
  • V3120. Potentially infinite loop. The variable in the loop exit condition does not change its value between iterations.
  • V3121. An enumeration was declared with 'Flags' attribute, but no initializers were set to override default values.
  • V3122. Uppercase (lowercase) string is compared with a different lowercase (uppercase) string.
  • Добавлена поддержка проверки Visual C++ проектов (.vcxproj) с Intel C++ toolset в плагине.

PVS-Studio 6.10 (25 октября 2016)

  • Мы выпустили PVS-Studio для Linux! Теперь проверять C и C++ код с помощью PVS-Studio можно не только в Windows, но и в Linux. Анализатор доступен в виде пакетов для основных систем управления пакетами, легко интегрируется в распространённые системы сборки. Вы можете ознакомиться с документацией по работе с Linux-версией PVS-Studio здесь.
  • В PVS-Studio для Windows новый интерфейс! Изменения произошли как в плагине для Visual Studio, так и в отдельном приложении Standalone.
  • В PVS-Studio включена новая утилита BlameNotifier. С помощью нее можно легко организовать рассылку по e-mail сообщений PVS-Studio, сопоставленных с авторами кода в репозитории. Поддерживаются Git, Svn, Mercurial. Подробнее о работе с результатами анализа можно прочитать здесь.
  • Добавлена поддержка проверки MSBuild проектов, использующих Intel C++ компилятор, при проверке кода из командной строки. Скоро мы добавим поддержку в плагине для Visual Studio.
  • V769. The pointer in the expression equals nullptr. The resulting value is meaningless and should not be used.
  • V770. Possible usage of a left shift operator instead of a comparison operator.

PVS-Studio 6.09 (6 октября 2016)

  • При отключении всех групп диагностик анализатора (С++ или C#) анализ проектов для соответствующего языка запускаться не будет.
  • Добавлена поддержка прокси с авторизацией при проверке обновлений и продлении триала.
  • Поддержана возможность полностью отключать C/C++ или C# анализатор в .pvsconfig файлах (//-V::C++ и //-V::C#).
  • В плагине SonarQube реализована функциональность для вычисления LOC и определения времени, необходимого для исправление найденных ошибок.
  • V768. The '!' operator is applied to an enumerator.
  • V3113. Consider inspecting the loop expression. It is possible that different variables are used inside initializer and iterator.
  • V3114. IDisposable object is not disposed before method returns.
  • V3115. It is not recommended to throw exceptions from 'Equals(object obj)' method.
  • V3116. Consider inspecting the 'for' operator. It's possible that the loop will be executed incorrectly or won't be executed at all.
  • V3117. Constructor parameter is not used.
  • V3118. A component of TimeSpan is used, which does not represent full time interval. Possibly 'Total*' value was intended instead.

PVS-Studio 6.08 (22 августа 2016)

  • В Visual Studio плагине отключена проверка из командной строки с помощью /command. Используйте отдельную утилиту PVS-Studio_Cmd.exe. Порядок работы с утилитой описан в документации.
  • V3108. It is not recommended to return null or throw exceptions from 'ToSting()' method.
  • V3109. The same sub-expression is present on both sides of the operator. The expression is incorrect or it can be simplified.
  • V3110. Possible infinite recursion.
  • V3111. Checking value for null will always return false when generic type is instantiated with a value type.
  • V3112. An abnormality within similar comparisons. It is possible that a typo is present inside the expression.

PVS-Studio 6.07 (8 августа 2016)

  • Мы движемся в сторону Linux! Пожалуйста, посмотрите, как запустить PVS-Studio в Linux.
  • PVS-Studio больше не поддерживает работу на 32-битных операционных системах. Анализатор PVS-Studio (как C++, так и C# модули) для своей работы требует большого объёма оперативной памяти, особенно при параллельной проверке на нескольких ядрах процессора. Максимальный объём памяти, доступный в 32-битной системе, позволяет корректно использовать анализатор одновременно только на одном ядре (т.е. одновременно в один процесс). Причём в случае очень крупных проектов, даже этого объёма памяти может оказаться недостаточно. В связи с этим, а также по причине того, что очень небольшой процент наших пользователей всё ещё используют 32-битные ОС, мы решили прекратить поддержку 32-битной версии анализатора. Это позволит нам сконцентрировать все наши ресурсы на развитие 64-битной версии.
  • В command line версии анализатора добавлена поддержка платформы непрерывного измерения качества SonarCube. Также в нашем дистрибутиве теперь есть плагин для интеграции результатов работы анализа с сервером SonarQube. Подробное описание плагина и новых режимов работы доступно здесь.
  • V763. Parameter is always rewritten in function body before being used.
  • V764. Possible incorrect order of arguments passed to function.
  • V765. A compound assignment expression 'X += X + N' is suspicious. Consider inspecting it for a possible error.
  • V766. An item with the same key has already been added.
  • V767. Suspicious access to element by a constant index inside a loop.
  • V3106. Possibly index is out of bound.
  • V3107. Identical expressions to the left and to the right of compound assignment.

PVS-Studio 6.06 (7 июля 2016)

  • V758. Reference invalidated, because of the destruction of the temporary object 'unique_ptr', returned by function.
  • V759. Violated order of exception handlers. Exception caught by handler for base class.
  • V760. Two identical text blocks detected. The second block starts with NN string.
  • V761. NN identical blocks were found.
  • V762. Consider inspecting virtual function arguments. See NN argument of function 'Foo' in derived class and base class.
  • V3105. The 'a' variable was used after it was assigned through null-conditional operator. NullReferenceException is possible.

PVS-Studio 6.05 (9 июня 2016)

  • Добавлена отдельная command line версия PVS-Studio, поддерживающая проверку vcxproj и csproj проектов (C++ и C#). Теперь нет необходимости использовать devenv.exe для ночных проверок. Подробнее об этом инструменте можно почитать здесь.
  • Прекращена поддержка MSBuild плагина. Вместо него предлагается использовать отдельную command line версию PVS-Studio.
  • V755. Copying from unsafe data source. Buffer overflow is possible.
  • V756. The 'X' counter is not used inside a nested loop. Consider inspecting usage of 'Y' counter.
  • V757. It is possible that an incorrect variable is compared with null after type conversion using 'dynamic_cast'.
  • V3094. Possible exception when deserializing type. The Ctor(SerializationInfo, StreamingContext) constructor is missing.
  • V3095. The object was used before it was verified against null. Check lines: N1, N2.
  • V3096. Possible exception when serializing type. [Serializable] attribute is missing.
  • V3097. Possible exception: type marked by [Serializable] contains non-serializable members not marked by [NonSerialized].
  • V3098. The 'continue' operator will terminate 'do { ... } while (false)' loop because the condition is always false.
  • V3099. Not all the members of type are serialized inside 'GetObjectData' method.
  • V3100. Unhandled NullReferenceException is possible. Unhandled exceptions in destructor lead to termination of runtime.
  • V3101. Potential resurrection of 'this' object instance from destructor. Without re-registering for finalization, destructor will not be called a second time on resurrected object.
  • V3102. Suspicious access to element by a constant index inside a loop.
  • V3103. A private Ctor(SerializationInfo, StreamingContext) constructor in unsealed type will not be accessible when deserializing derived types.
  • V3104. 'GetObjectData' implementation in unsealed type is not virtual, incorrect serialization of derived type is possible.

PVS-Studio 6.04 (16 мая 2016)

  • V753. The '&=' operation always sets a value of 'Foo' variable to zero.
  • V754. The expression of 'foo(foo(x))' pattern is excessive or contains an error.
  • V3082. The 'Thread' object is created but is not started. It is possible that a call to 'Start' method is missing.
  • V3083. Unsafe invocation of event, NullReferenceException is possible. Consider assigning event to a local variable before invoking it.
  • V3084. Anonymous function is used to unsubscribe from event. No handlers will be unsubscribed, as a separate delegate instance is created for each anonymous function declaration.
  • V3085. The name of 'X' field/property in a nested type is ambiguous. The outer type contains static field/property with identical name.
  • V3086. Variables are initialized through the call to the same function. It's probably an error or un-optimized code.
  • V3087. Type of variable enumerated in 'foreach' is not guaranteed to be castable to the type of collection's elements.
  • V3088. The expression was enclosed by parentheses twice: ((expression)). One pair of parentheses is unnecessary or misprint is present.
  • V3089. Initializer of a field marked by [ThreadStatic] attribute will be called once on the first accessing thread. The field will have default value on different threads.
  • V3090. Unsafe locking on an object.
  • V3091. Empirical analysis. It is possible that a typo is present inside the string literal. The 'foo' word is suspicious.
  • V3092. Range intersections are possible within conditional expressions.
  • V3093. The operator evaluates both operands. Perhaps a short-circuit operator should be used instead.

PVS-Studio 6.03 (5 апреля 2016)

  • V751. Parameter is not used inside method's body.
  • V752. Creating an object with placement new requires a buffer of large size.
  • V3072. The 'A' class containing IDisposable members does not itself implement IDisposable.
  • V3073. Not all IDisposable members are properly disposed. Call 'Dispose' when disposing 'A' class.
  • V3074. The 'A' class contains 'Dispose' method. Consider making it implement 'IDisposable' interface.
  • V3075. The operation is executed 2 or more times in succession.
  • V3076. Comparison with 'double.NaN' is meaningless. Use 'double.IsNaN()' method instead.
  • V3077. Property setter / event accessor does not utilize its 'value' parameter.
  • V3078. Original sorting order will be lost after repetitive call to 'OrderBy' method. Use 'ThenBy' method to preserve the original sorting.
  • V3079. 'ThreadStatic' attribute is applied to a non-static 'A' field and will be ignored.
  • V3080. Possible null dereference.
  • V3081. The 'X' counter is not used inside a nested loop. Consider inspecting usage of 'Y' counter.
  • V051. Some of the references in project are missing or incorrect. The analysis results could be incomplete. Consider making the project fully compilable and building it before analysis.

PVS-Studio 6.02 (9 марта 2016)

  • V3057. Function receives an odd argument.
  • V3058. An item with the same key has already been added.
  • V3059. Consider adding '[Flags]' attribute to the enum.
  • V3060. A value of variable is not modified. Consider inspecting the expression. It is possible that other value should be present instead of '0'.
  • V3061. Parameter 'A' is always rewritten in method body before being used.
  • V3062. An object is used as an argument to its own method. Consider checking the first actual argument of the 'Foo' method.
  • V3063. A part of conditional expression is always true/false.
  • V3064. Division or mod division by zero.
  • V3065. Parameter is not utilized inside method's body.
  • V3066. Possible incorrect order of arguments passed to 'Foo' method.
  • V3067. It is possible that 'else' block was forgotten or commented out, thus altering the program's operation logics.
  • V3068. Calling overrideable class member from constructor is dangerous.
  • V3069. It's possible that the line was commented out improperly, thus altering the program's operation logics.
  • V3070. Uninitialized variables are used when initializing the 'A' variable.
  • V3071. The object is returned from inside 'using' block. 'Dispose' will be invoked before exiting method.

PVS-Studio 6.01 (3 февраля 2016)

  • V736. The behavior is undefined for arithmetic or comparisons with pointers that do not point to members of the same array.
  • V737. It is possible that ',' comma is missing at the end of the string.
  • V738. Temporary anonymous object is used.
  • V739. EOF should not be compared with a value of the 'char' type. Consider using the 'int' type.
  • V740. Because NULL is defined as 0, the exception is of the 'int' type. Keyword 'nullptr' could be used for 'pointer' type exception.
  • V741. The following pattern is used: throw (a, b);. It is possible that type name was omitted: throw MyException(a, b);..
  • V742. Function receives an address of a 'char' type variable instead of pointer to a buffer.
  • V743. The memory areas must not overlap. Use 'memmove' function.
  • V744. Temporary object is immediately destroyed after being created. Consider naming the object.
  • V745. A 'wchar_t *' type string is incorrectly converted to 'BSTR' type string.
  • V746. Object slicing. An exception should be caught by reference rather than by value.
  • V747. An odd expression inside parenthesis. It is possible that a function name is missing.
  • V748. Memory for 'getline' function should be allocated only by 'malloc' or 'realloc' functions. Consider inspecting the first parameter of 'getline' function.
  • V749. Destructor of the object will be invoked a second time after leaving the object's scope.
  • V750. BSTR string becomes invalid. Notice that BSTR strings store their length before start of the text.
  • V816. It is more efficient to catch exception by reference rather than by value.
  • V3042. Possible NullReferenceException. The '?.' and '.' operators are used for accessing members of the same object.
  • V3043. The code's operational logic does not correspond with its formatting.
  • V3044. WPF: writing and reading are performed on a different Dependency Properties.
  • V3045. WPF: the names of the property registered for DependencyProperty, and of the property used to access it, do not correspond with each other.
  • V3046. WPF: the type registered for DependencyProperty does not correspond with the type of the property used to access it.
  • V3047. WPF: A class containing registered property does not correspond with a type that is passed as the ownerType.type.
  • V3048. WPF: several Dependency Properties are registered with a same name within the owner type.
  • V3049. WPF: readonly field of 'DependencyProperty' type is not initialized.
  • V3050. Possibly an incorrect HTML. The </XX> closing tag was encountered, while the </YY> tag was expected.
  • V3051. An excessive type cast or check. The object is already of the same type.
  • V3052. The original exception object was swallowed. Stack of original exception could be lost.
  • V3053. An excessive expression. Examine the substrings "abc" and "abcd".
  • V3054. Potentially unsafe double-checked locking. Use volatile variable(s) or synchronization primitives to avoid this.
  • V3055. Suspicious assignment inside the condition expression of 'if/while/for' operator.
  • V3056. Consider reviewing the correctness of 'X' item's usage.

PVS-Studio 6.00 (22 декабря 2015)

  • Появился статический анализ кода для C#: в первой версии более 40 диагностик.
  • Прекращена поддержка Visual Studio 2005 и Visual Studio 2008.
  • V734. Searching for the longer substring is meaningless after searching for the shorter substring.
  • V735. Possibly an incorrect HTML. The "</XX" closing tag was encountered, while the "</YY" tag was expected.
  • V3001. There are identical sub-expressions to the left and to the right of the 'foo' operator.
  • V3002. The switch statement does not cover all values of the enum.
  • V3003. The use of 'if (A) {...} else if (A) {...}' pattern was detected. There is a probability of logical error presence.
  • V3004. The 'then' statement is equivalent to the 'else' statement.
  • V3005. The 'x' variable is assigned to itself.
  • V3006. The object was created but it is not being used. The 'throw' keyword could be missing.
  • V3007. Odd semicolon ';' after 'if/for/while' operator.
  • V3008. The 'x' variable is assigned values twice successively. Perhaps this is a mistake.
  • V3009. It's odd that this method always returns one and the same value of NN.
  • V3010. The return value of function 'Foo' is required to be utilized.
  • V3011. Two opposite conditions were encountered. The second condition is always false.
  • V3012. The '?:' operator, regardless of its conditional expression, always returns one and the same value.
  • V3013. It is odd that the body of 'Foo_1' function is fully equivalent to the body of 'Foo_2' function.
  • V3014. It is likely that a wrong variable is being incremented inside the 'for' operator. Consider reviewing 'X'.
  • V3015. It is likely that a wrong variable is being compared inside the 'for' operator. Consider reviewing 'X'.
  • V3016. The variable 'X' is being used for this loop and for the outer loop.
  • V3017. A pattern was detected: A || (A && ...). The expression is excessive or contains a logical error.
  • V3018. Consider inspecting the application's logic. It's possible that 'else' keyword is missing.
  • V3019. It is possible that an incorrect variable is compared with null after type conversion using 'as' keyword.
  • V3020. An unconditional 'break/continue/return/goto' within a loop.
  • V3021. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains method return. This means that the second 'if' statement is senseless.
  • V3022. Expression is always true/false.
  • V3023. Consider inspecting this expression. The expression is excessive or contains a misprint.
  • V3024. An odd precise comparison. Consider using a comparison with defined precision: Math.Abs(A - B) < Epsilon or Math.Abs(A - B) > Epsilon.
  • V3025. Incorrect format. Consider checking the N format items of the 'Foo' function.
  • V3026. The constant NN is being utilized. The resulting value could be inaccurate. Consider using the KK constant.
  • V3027. The variable was utilized in the logical expression before it was verified against null in the same logical expression.
  • V3028. Consider inspecting the 'for' operator. Initial and final values of the iterator are the same.
  • V3029. The conditional expressions of the 'if' operators situated alongside each other are identical.
  • V3030. Recurring check. This condition was already verified in previous line.
  • V3031. An excessive check can be simplified. The operator '||' operator is surrounded by opposite expressions 'x' and '!x'.
  • V3032. Waiting on this expression is unreliable, as compiler may optimize some of the variables. Use volatile variable(s) or synchronization primitives to avoid this.
  • V3033. It is possible that this 'else' branch must apply to the previous 'if' statement.
  • V3034. Consider inspecting the expression. Probably the '!=' should be used here.
  • V3035. Consider inspecting the expression. Probably the '+=' should be used here.
  • V3036. Consider inspecting the expression. Probably the '-=' should be used here.
  • V3037. An odd sequence of assignments of this kind: A = B; B = A;.
  • V3038. The 'first' argument of 'Foo' function is equal to the 'second' argument
  • V3039. Consider inspecting the 'Foo' function call. Defining an absolute path to the file or directory is considered a poor style.
  • V3040. The expression contains a suspicious mix of integer and real types.
  • V3041. The expression was implicitly cast from integer type to real type. Consider utilizing an explicit type cast to avoid the loss of a fractional part.

PVS-Studio 5.31 (3 ноября 2015)

  • Снижено количество ложных срабатываний для некоторых диагностик.

PVS-Studio 5.30 (29 октября 2015)

  • Добавлена поддержка навигации по многострочным сообщениям с помощью двойного клика.
  • Исправлена ошибка доступа при запуске препроцессора Visual C++ для проверки файлов, использующих директиву #import.
  • Исправлена ошибка работы Compiler Monitoring при длительности препроцессирования более 10 минут.
  • Исправлена некорректная работа инсталлятора на системах, имеющих только 2015 версию Visual Studio.
  • Новая диагностика – V728. An excessive check can be simplified. The '||' operator is surrounded by opposite expressions 'x' and '!x'.
  • Новая диагностика – V729. Function body contains the 'X' label that is not used by any 'goto' statements.
  • Новая диагностика – V730. Not all members of a class are initialized inside the constructor.
  • Новая диагностика – V731. The variable of char type is compared with pointer to string.
  • Новая диагностика – V732. Unary minus operator does not modify a bool type value.
  • Новая диагностика – V733. It is possible that macro expansion resulted in incorrect evaluation order.

PVS-Studio 5.29 (22 сентября 2015)

  • Добавлена поддержка Visual Studio 2015.
  • Добавлена поддержка Windows 10.
  • Новая диагностика – V727. Return value of 'wcslen' function is not multiplied by 'sizeof(wchar_t)'.

PVS-Studio 5.28 (10 августа, 2015)

  • Новый интерфейс страниц настроек Detectable Errors, Don't Check Files и Keyword Message Filering.
  • Добавлена утилита PlogConverter для преобразования XML plog файлов в текстовый, html и CSV форматы. Подробности в документации.

PVS-Studio 5.27 (28 июля, 2015)

  • Новая диагностика – V207. A 32-bit variable is utilized as a reference to a pointer. A write outside the bounds of this variable may occur.
  • Новая диагностика - V726. An attempt to free memory containing the 'int A[10]' array by using the 'free(A)' function.
  • Новая возможность - Формирование статистики работы анализатора в виде графиков. Анализатор PVS-Studio позволяет собирать статистику своей работы - количество найденных сообщений (включая подавленные) на разных уровнях и группах диагностик. Собранная статистика может быть отфильтрована и отображена в виде графика в документе Microsoft Excel, показывающего динамику изменения сообщений в проверяемом проекте. Подробнее в документации.
  • Удален режим проверки заранее препроцессированных файлов в Standalone.

PVS-Studio 5.26 (30 июня, 2015)

  • Новая диагностика – V723. Function returns a pointer to the internal string buffer of a local object, which will be destroyed.
  • Новая диагностика – V724. Converting integers or pointers to BOOL can lead to a loss of high-order bits. Non-zero value can become 'FALSE'.
  • Новая диагностика – V725. A dangerous cast of 'this' to 'void*' type in the 'Base' class, as it is followed by a subsequent cast to 'Class' type.
  • Добавлена поддержка подавления сообщений (Message Suppression) в CLMonitoring/Standalone.
  • 2 и 3 уровни сообщений анализатора доступны в Trial режиме.

PVS-Studio 5.25 (12 мая 2015)

  • Новая диагностика – V722. An abnormality within similar comparisons. It is possible that a typo is present inside the expression.
  • Улучшена "отзывчивость" интерфейса функций выбора анализаторов и команды Quick Filters в окне PVS-Studio Output Window.
  • Кнопка 'False Alarms' перемещена из окна PVS-Studio в настройки анализатора.
  • Исправлена ошибка 'An item with the same key has already been added', возникающая при использовании механизма массового подавления сообщений.

PVS-Studio 5.24 (10 апреля 2015)

PVS-Studio 5.23 (17 марта 2015)

  • Существенно улучшен анализатор проблем 64-битных приложений. Теперь если вы хотите исправить основные проблемы 64-битного кода, вам достаточно поправить все сообщения 1 уровня в 64-битном анализе.
  • Теперь вы можете использовать автоматическое обновление PVS-Studio на билд-сервере. Подробнее здесь.
  • Новая диагностика – V719. The switch statement does not cover all values of the enum.
  • Новая диагностика – V720. It is advised to utilize the 'SuspendThread' function only when developing a debugger (see documentation for details).
  • Новая диагностика – V221. Suspicious sequence of types castings: pointer -> memsize -> 32-bit integer.
  • Новая диагностика – V2013. Consider inspecting the correctness of handling the N argument in the 'Foo' function.

PVS-Studio 5.22 (17 февраля 2015)

  • Новая диагностика – V718. The 'Foo' function should not be called from 'DllMain' function.
  • Исправлена работа CLMonitoring с C++/CLI проектами.
  • Исправлена утечка памяти при длительной работе CLMonitoring.
  • Новая система поиска include\символов в Standalone.
  • Оптимизировано потребление памяти при использовании функции подавления сообщений (Message Suppression).
  • В системе подавления (Message Suppression) добавлена поддержка сообщений, выдаваемых на несколько IDE проектов (например, сообщения на общие h файлы).
  • Улучшена логика работы системы подавления сообщений (Message Suppression).

PVS-Studio 5.21 (11 декабря 2014)

  • Мы прекратили поддержку среды разработки Embarcadero RAD Studio.
  • Мы прекратили поддержку диагностик проблем OpenMP (набор правил VivaMP).
  • Новая диагностика – V711. It is dangerous to create a local variable within a loop with a same name as a variable controlling this loop.
  • Новая диагностика – V712. Be advised that compiler may delete this cycle or make it infinity. Use volatile variable(s) or synchronization primitives to avoid this.
  • Новая диагностика – V713. The pointer was utilized in the logical expression before it was verified against nullptr in the same logical expression.
  • Новая диагностика – V714. Variable is not passed into foreach loop by a reference, but its value is changed inside of the loop.
  • Новая диагностика – V715. The 'while' operator has empty body. Suspicious pattern detected.
  • Новая диагностика – V716. Suspicious type conversion: HRESULT -> BOOL (BOOL -> HRESULT).
  • Новая диагностика – V717. It is strange to cast object of base class V to derived class U.

PVS-Studio 5.20 (12 ноября 2014)

  • Новая диагностика – V706. Suspicious division: sizeof(X) / Value. Size of every element in X array does not equal to divisor.
  • Новая диагностика – V707. Giving short names to global variables is considered to be bad practice.
  • Новая диагностика – V708. Dangerous construction is used: 'm[x] = m.size()', where 'm' is of 'T' class. This may lead to undefined behavior.
  • Новая диагностика – V709. Suspicious comparison found: 'a == b == c'. Remember that 'a == b == c' is not equal to 'a == b && b == c.
  • Новая диагностика – V710. Suspicious declaration found. There is no point to declare constant reference to a number.
  • Новая диагностика – V2012. Possibility of decreased performance. It is advised to pass arguments to std::unary_function/std::binary_function template as references.
  • Новая возможность - Массовое подавление сообщений анализатора. Иногда на стадии внедрения статического анализа, особенно на крупных проектах, разработчик не хочет (или даже не имеет возможности) править сотни, а иногда и тысячи, сообщений анализатора, сгенерированных на существующую кодовую базу. В такой ситуации возникает необходимость "убрать" все выданные на текущий код сообщения, и в дальнейшем работать только с сообщениями, относящимися к вновь написанному или модифицированному коду, т.е. коду, который ещё не отлажен и может потенциально содержать большое количество ошибок.

PVS-Studio 5.19 (18 сентября 2014)

  • Новая диагностика – V698. strcmp()-like functions can return not only the values -1, 0 and 1, but any values.
  • Новая диагностика – V699. Consider inspecting the 'foo = bar = baz ? .... : ....' expression. It is possible that 'foo = bar == baz ? .... : ....' should be used here instead.
  • Новая диагностика – V700. Consider inspecting the 'T foo = foo = x;' expression. It is odd that variable is initialized through itself.
  • Новая диагностика – V701. realloc() possible leak: when realloc() fails in allocating memory, original pointer is lost. Consider assigning realloc() to a temporary pointer.
  • Новая диагностика – V702. Classes should always be derived from std::exception (and alike) as 'public'.
  • Новая диагностика – V703. It is odd that the 'foo' field in derived class overwrites field in base class.
  • Новая диагностика – V704. 'this == 0' comparison should be avoided - this comparison is always false on newer compilers.
  • Новая диагностика – V705. It is possible that 'else' block was forgotten or commented out, thus altering the program's operation logics.

PVS-Studio 5.18 (30 июля 2014)

  • ClMonitoring - автоматическое определение платформы компилятора.
  • ClMonitoring - увеличение скорости работы за счёт уменьшения влияния антивирусов на этапе препроцессирования проверяемых файлов.
  • CLMonitoring - исправлена некорректная обработка 64-битных процессов после системного обновления .NET Framework 4.
  • Новая диагностика – V695. Range intersections are possible within conditional expressions.
  • Новая диагностика – V696. The 'continue' operator will terminate 'do { ... } while (FALSE)' loop because the condition is always false.
  • Новая диагностика – V697. A number of elements in the allocated array is equal to size of a pointer in bytes.
  • Новая диагностика – V206. Explicit conversion from 'void *' to 'int *'.
  • Новая диагностика – V2011. Consider inspecting signed and unsigned function arguments. See NN argument of function 'Foo' in derived class and base class.

PVS-Studio 5.17 (20 мая 2014)

  • Новая диагностика – V690. The class implements a copy constructor/operator=, but lacks the the operator=/copy constructor.
  • Новая диагностика – V691. Empirical analysis. It is possible that a typo is present inside the string literal. The 'foo' word is suspicious.
  • Новая диагностика – V692. An inappropriate attempt to append a null character to a string. To determine the length of a string by 'strlen' function correctly, a string ending with a null terminator should be used in the first place.
  • Новая диагностика – V693. Consider inspecting conditional expression of the loop. It is possible that 'i < X.size()' should be used instead of 'X.size()'.
  • Новая диагностика – V694. The condition (ptr - const_value) is only false if the value of a pointer equals a magic constant.
  • Новая диагностика – V815. Decreased performance. Consider replacing the expression 'AA' with 'BB'.
  • Новая диагностика – V2010. Handling of two different exception types is identical.

PVS-Studio 5.16 (29 апреля 2014)

  • Существенно улучшена поддержка С++/CLI. проектов.
  • Плагин TFSRipper был удален.
  • Исправлено падение в Standalone при установке в место не по умолчанию на 64-битных системах.
  • Исправлена ошибка из-за которой в некоторых ситуациях не показывались некоторые диагностические сообщения.

PVS-Studio 5.15 (14 апреля 2014)

  • Новая диагностика – V689. The destructor of the 'Foo' class is not declared as a virtual. It is possible that a smart pointer will not destroy an object correctly.
  • Существенные улучшения в подсистеме Мониторинг компилятора в PVS-Studio.

PVS-Studio 5.14 (12 марта 2014)

  • Новая опция "DIsable 64-bit Analysis" в специальных настройках анализатора позволяет немного увеличить скорость анализа и существенно уменьшить размер .plog файла.
  • Новая возможность: Мониторинг компилятора в PVS-Studio.
  • Исправлена проблема с нотификацией при инкрементальном анализе и окне PVS-Studio со стилем auto hide.
  • Новая диагностика – V687. Size of an array calculated by the sizeof() operator was added to a pointer. It is possible that the number of elements should be calculated by sizeof(A)/sizeof(A[0]).
  • Новая диагностика – V688. The 'foo' local variable possesses the same name as one of the class members, which can result in a confusion.

PVS-Studio 5.13 (5 февраля 2014)

  • Добавлена поддержка для Emarcadero RAD Studio XE5.
  • Новая диагностика – V684. A value of variable is not modified. Consider inspecting the expression. It is possible that '1' should be present instead of '0'.
  • Новая диагностика – V685. Consider inspecting the return statement. The expression contains a comma.
  • Новая диагностика – V686. A pattern was detected: A || (A && ...). The expression is excessive or contains a logical error.

PVS-Studio 5.12 (23 декабря 2013)

  • Исправлена ошибка при работе в режиме прямой интеграции в сборку MSBuild для проектов, использующих свойство SolutionDir.
  • Появилась возможность запуска проверки из контекстного меню Solution Explorer.
  • Теперь в окне PVS-Studio Output Window по умолчанию не показывается ID сообщения об ошибке. Вернуть показ ID можно с помощью команды Show Columns -> ID.
  • Новая диагностика – V682. Suspicious literal is present: '/r'. It is possible that a backslash should be used here instead: '\r'.
  • Новая диагностика – V683. Consider inspecting the loop expression. It is possible that the 'i' variable should be incremented instead of the 'n' variable.

PVS-Studio 5.11 (6 ноября 2013)

  • Поддержана release-версия Microsoft Visual Studio 2013.
  • Новая диагностика – V680. The 'delete A, B' expression only destroys the 'A' object. Then the ',' operator returns a resulting value from the right side of the expression.
  • Новая диагностика – V681. The language standard does not define an order in which the 'Foo' functions will be called during evaluation of arguments.

PVS-Studio 5.10 (7 октября 2013)

  • Исправлена работа анализатора при запуске Visual Studio с параметром /useenv: devenv.exe /useenv.
  • В VS2012 наконец-то стало возможно использовать Clang в качестве препроцессора. Для пользователей PVS-Studio это означает существенное увеличение скорости работы анализатора в VS2012.
  • Серьезно улучшена работа анализатора при разборе кода в среде VS2012.
  • В дистрибутиве PVS-Studio появилось новое приложение Standalone.
  • Появилась возможность экспорта результатов анализа в .CSV-файл для дальнейшей работы с ним из Excel.
  • Существенно улучшена поддержка precompiled headers в Visual Studio и MSBuild.
  • Новая диагностика – V676. It is incorrect to compare the variable of BOOL type with TRUE.
  • Новая диагностика – V677. Custom declaration of a standard type. The declaration from system header files should be used instead.
  • Новая диагностика – V678. An object is used as an argument to its own method. Consider checking the first actual argument of the 'Foo' function.
  • Новая диагностика – V679. The 'X' variable was not initialized. This variable is passed by a reference to the 'Foo' function in which its value will be utilized.

PVS-Studio 5.06 (13 августа 2013)

  • Исправлено некорректное определение числа файлов при использовании команды 'Check Open File(s)' в среде Visual Studio 2010.
  • Новая диагностика – V673. More than N bits are required to store the value, but the expression evaluates to the T type which can only hold K bits.
  • Новая диагностика – V674. The expression contains a suspicious mix of integer and real types.
  • Новая диагностика – V675. Writing into the read-only memory.
  • Новая диагностика – V814. Decreased performance. The 'strlen' function was called multiple times inside the body of a loop.

PVS-Studio 5.05 (28 мая 2013)

  • Добавлена поддержка прокси-сервера с авторизацией для окна продления триал-режима.
  • Исправлена проблема с использованием некоторых специальных символов в фильтрах диагностических сообщений.
  • Часть настроек страницы Common Analyzer Settings и все настройки страницы Customer Specific Settings объединены в новую страницу настроек: Specific Analyzer Settings.
  • Реализована настройка SaveModifiedLog, позволяющая определить поведение диалога сохранения нового\модифицированного отчёта работы анализатора (всегда спрашивать, сохранять автоматически, не сохранять).
  • Пользовательские диагностики (V20xx) выделены в отдельную группу (CS – Customer Specific).
  • Добавлена новая команда меню "Check Open File(s)", позволяющая проверить все открытые в редакторе IDE исходные C/C++ файлы.

PVS-Studio 5.04 (14 мая 2013)

  • Добавлена поддержка C++Builder XE4. Теперь PVS-Studio поддерживает следующие версии C++Builder: XE4, XE3 Update 1, XE2, XE, 2010, 2009.
  • Новая диагностика – V669. The argument is a non-constant reference. The analyzer is unable to determine the position at which this argument is being modified. It is possible that the function contains an error.
  • Новая диагностика – V670. An uninitialized class member is used to initialize another member. Remember that members are initialized in the order of their declarations inside a class.
  • Новая диагностика – V671. It is possible that the 'swap' function interchanges a variable with itself.
  • Новая диагностика – V672. There is probably no need in creating a new variable here. One of the function's arguments possesses the same name and this argument is a reference.
  • Новая диагностика – V128. A variable of the memsize type is read from a stream. Consider verifying the compatibility of 32 and 64 bit versions of the application in the context of a stored data.
  • Новая диагностика – V813. Decreased performance. The argument should probably be rendered as a constant pointer/reference.
  • Новая диагностика – V2009. Consider passing the 'Foo' argument as a constant pointer/reference.

PVS-Studio 5.03 (16 апреля 2013)

  • Улучшена производительность анализа/интерфейса при проверке крупных проектов и генерации большого числа диагностических сообщений (имеется в виду общее количество неотфильтрованных сообщений).
  • Исправлена некорректная интеграция плагина PVS-Studio в среды разработки C++Builder 2009/2010/XE после установки.
  • Исправлена ошибка работы в trial-режиме.
  • Добавлена возможность использовать относительные пути в файлах-отчётах анализатора.
  • Реализована поддержка прямой интеграции анализатора в сборочную систему MSBuild.
  • Появилась настройка IntegratedHelpLanguage на странице Customer's Settings. Настройка позволяет задать язык для встроенной справки по диагностическим сообщениям (клик по коду ошибки в окне вывода сообщений PVS-Studio) и документации (команда меню PVS-Studio -> Help -> Open PVS-Studio Documentation (html, online)) PVS-Studio, доступных на нашем сайте. Данная настройка не изменяет языка интерфейса IDE плагина PVS-Studio или выдаваемых анализатором диагностических сообщений.
  • Исправлен режим запуска анализа из командной строки для Visual Studio 2012 в случае фоновой подгрузки проектов.
  • Новая диагностика – V665. Possibly, the usage of '#pragma warning(default: X)' is incorrect in this context. The '#pragma warning(push/pop)' should be used instead.
  • Новая диагностика – V666. Consider inspecting NN argument of the function 'Foo'. It is possible that the value does not correspond with the length of a string which was passed with the YY argument.
  • Новая диагностика – V667. The 'throw' operator does not possess any arguments and is not situated within the 'catch' block.
  • Новая диагностика – V668. There is no sense in testing the pointer against null, as the memory was allocated using the 'new' operator. The exception will be generated in the case of memory allocation error.
  • Новая диагностика – V812. Decreased performance. Ineffective use of the 'count' function. It can possibly be replaced by the call to the 'find' function.

PVS-Studio 5.02 (6 марта 2013)

  • Исправлена некорректная навигация у C++Builder модулей, содержащих несколько заголовочных\исходных файлов.
  • Добавлена возможность вставки пользовательских комментариев (например, для использования в системах автоматической генерации документации) при разметке кода маркерами ложных срабатываний (False Alarm).
  • Исправлен некорректный запуск C++ препроцессора у некоторых файлов, использующих precompiled заголовки.
  • Новая диагностика – V663. Infinite loop is possible. The 'cin.eof()' condition is insufficient to break from the loop. Consider adding the 'cin.fail()' function call to the conditional expression.
  • Новая диагностика – V664. The pointer is being dereferenced on the initialization list before it is verified against null inside the body of the constructor function.
  • Новая диагностика – V811. Decreased performance. Excessive type casting: string -> char * -> string.

PVS-Studio 5.01 (13 февраля 2013)

  • Добавлена поддержка некоторых прошлых версий C++Builder. Теперь PVS-Studio поддерживает следующие версии C++Builder: XE3 Update 1, XE2, XE, 2010, 2009.
  • Исправлена ошибка, связанная с некорректным запуском инкрементального анализа в версии для C++Builder в некоторых ситуациях.
  • Исправлена ошибка с функцией Mark As False Alarm в версии для C++Builder.
  • Исправлена ошибка связанная неправильным отображением локализованных имен файлов в версии для C++Builder.
  • Исправлена проблема с открытием исходных файлов при переходе по диагностическому сообщению в версии для C++Buidler.
  • Исправлена неполная обработка системных include путей при запуске препроцессора для анализатора в версии для C++Builder.
  • Новая диагностика – V661. A suspicious expression 'A[B < C]'. Probably meant 'A[B] < C'.
  • Новая диагностика – V662. Consider inspecting the loop expression. Different containers are utilized for setting up initial and final values of the iterator.

PVS-Studio 5.00 (31 января 2013)

  • Появилась интеграция в Embarcadero RAD Studio, точнее в Embarcadero C++Builder! Теперь пользователям C++Builder доступны диагностические возможности PVS-Studio. Если раньше PVS-Studio можно было удобно использовать только в Visual Studio окружении, то теперь C++-разработчики, выбравшие продукты Embarcadero также могут использовать инструмент статического анализа PVS-Studio. В настоящее время поддерживаются версии XE2 и XE3, включая XE3 Update 1 с поддержкой 64-битного компилятора.
  • Реализована поддержка Microsoft Design Language (ранее известного как Metro Language) C++/CX проектов для Windows 8 Store (WinRT) на платформах x86/ARM и Windows Phone 8 проектов.
  • Исправление для пользователей Clang-препроцессора в версии для Visual Studio. Раньше при проверке Boost-проектов были ошибки препроцессирования, из-за которых в таких проектах нельзя было использовать Clang в качестве препроцессора. В настоящее время эти ошибки устранены. Это позволяет существенно быстрее проверять проекты с Boost при использовании препроцессора Clang.
  • Удалена страница настроек Viva64, так как она устарела.
  • Переименовано сообщение V004 – теперь оно более корректно.
  • Новая диагностика – V810. Decreased performance. The 'A' function was called several times with identical arguments. The result should possibly be saved to a temporary variable, which then could be used while calling the 'B' function.
  • Новая диагностика – V2008. Cyclomatic complexity: NN. Consider refactoring the 'Foo' function.
  • Новая диагностика – V657. It's odd that this function always returns one and the same value of NN.
  • Новая диагностика – V658. A value is being subtracted from the unsigned variable. This can result in an overflow. In such a case, the comparison operation can potentially behave unexpectedly.
  • Новая диагностика – V659. Declarations of functions with 'Foo' name differ in the 'const' keyword only, but the bodies of these functions have different composition. This is suspicious and can possibly be an error.
  • Новая диагностика – V660. The program contains an unused label and a function call: 'CC:AA()'. It's possible that the following was intended: 'CC::AA()'.

PVS-Studio 4.77 (11 декабря 2012)

  • Улучшен сбор параметров компиляции для VS2012 и VS2010 за счет расширения поддержки MSBuild.
  • Новая диагностика – V654. The condition of loop is always true/false.
  • Новая диагностика – V655. The strings was concatenated but are not utilized. Consider inspecting the expression.
  • Новая диагностика – V656. Variables are initialized through the call to the same function. It's probably an error or un-optimized code.
  • Новая диагностика – V809. Verifying that a pointer value is not NULL is not required. The 'if (ptr != NULL)' check can be removed.

PVS-Studio 4.76 (23 ноября 2012)

  • Исправлены некоторые ошибки.

PVS-Studio 4.75 (12 ноября 2012)

  • Исправлена ошибка, проявляющаяся в некоторых определенных условиях при проверке проектов на основе библиотеки Qt (подробности в блоге).
  • Новая диагностика – V646. Consider inspecting the application's logic. It's possible that 'else' keyword is missing.
  • Новая диагностика – V647. The value of 'A' type is assigned to the pointer of 'B' type.
  • Новая диагностика – V648. Priority of the '&&' operation is higher than that of the '||' operation.
  • Новая диагностика – V649. There are two 'if' statements with identical conditional expressions. The first 'if' statement contains function return. This means that the second 'if' statement is senseless.
  • Новая диагностика – V650. Type casting operation is utilized 2 times in succession. Next, the '+' operation is executed. Probably meant: (T1)((T2)a + b).
  • Новая диагностика – V651. An odd operation of the 'sizeof(X)/sizeof(T)' kind is performed, where 'X' is of the 'class' type.
  • Новая диагностика – V652. The operation is executed 3 or more times in succession.
  • Новая диагностика – V653. A suspicious string consisting of two parts is used for array initialization. It is possible that a comma is missing.
  • Новая диагностика – V808. An array/object was declared but was not utilized.
  • Новая диагностика – V2007. This expression can be simplified. One of the operands in the operation equals NN. Probably it is a mistake.

PVS-Studio 4.74 (16 октября 2012)

  • Новая опция "Incremental Results Display Depth". Настройка задаёт режим отображения уровней сообщений в окне PVS-Studio Output для результатов работы инкрементального анализа. Установка в данном поле глубины уровня отображения (соответственно, только 1 уровень; 1 и 2 уровни; 1, 2 и 3 уровни) приведёт к автоматическому включению данных уровней после завершения инкрементального анализа.
  • Новая опция "External Tool Path". Данное поле позволяет задать абсолютный путь до любой внешней утилиты, которую можно запустить с помощью команды контекстного меню "Send this message to external tool" окна PVS-Studio Output. Данная команда доступна для одного одновременно выделенного сообщения в таблице результатов, позволяя передать в заданную здесь утилиту определённые в поле настроек ExternalToolCommandLine параметры командной строки. Подробное описание этого режима с примерами доступно по этой ссылке.

PVS-Studio 4.73 (17 сентября 2012)

  • Исправлены ошибки в обработке некоторых C++11 конструкций из Visual Studio 2012.
  • Реализована полная поддержка тем для Visual Studio 2012.
  • Добавлен быстрый по полю Project в окне PVS-Studio Output Window.
  • Обновлена версия Clang, используемого в качестве препроцессора.
  • Добавлена поддержка TenAsys INtime.

PVS-Studio 4.72 (30 августа 2012)

  • Поддержка финальной версии Microsoft Visual Studio 2012.
  • Используется новая версия компонента SourceGrid благодаря чему исправлено несколько недостатков, проявляющихся при работе с окном PVS-Studio Output Window.
  • Поддержана диагностика проблем в библиотеке STL при использовании STLport.
  • Новая диагностика – V636. The expression was implicitly casted from integer type to real type. Consider utilizing an explicit type cast to avoid overflow or loss of a fractional part.
  • Новая диагностика – V637. Two opposite conditions were encountered. The second condition is always false.
  • Новая диагностика – V638. A terminal null is present inside a string. The '\0xNN' characters were encountered. Probably meant: '\xNN'.
  • Новая диагностика – V639. Consider inspecting the expression for function call. It is possible that one of the closing ')' brackets was positioned incorrectly.
  • Новая диагностика – V640. Consider inspecting the application's logic. It is possible that several statements should be braced.
  • Новая диагностика – V641. The size of the allocated memory buffer is not a multiple of the element size.
  • Новая диагностика – V642. Saving the function result inside the 'byte' type variable is inappropriate. The significant bits could be lost breaking the program's logic.
  • Новая диагностика – V643. Unusual pointer arithmetic. The value of the 'char' type is being added to the string pointer.
  • Новая диагностика – V644. A suspicious function declaration. It is possible that the T type object was meant to be created.
  • Новая диагностика – V645. The function call could lead to the buffer overflow. The bounds should not contain the size of the buffer, but a number of characters it can hold.

PVS-Studio 4.71 (20 июля 2012)

  • Новая диагностика – V629. Consider inspecting the expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type.
  • Новая диагностика – V630. The 'malloc' function is used to allocate memory for an array of objects which are classes containing constructors/destructors.
  • Новая диагностика – V631. Consider inspecting the 'Foo' function call. Defining an absolute path to the file or directory is considered a poor style.
  • Новая диагностика – V632. Consider inspecting the NN argument of the 'Foo' function. It is odd that the argument is of the 'T' type.
  • Новая диагностика – V633. Consider inspecting the expression. Probably the '!=' should be used here.
  • Новая диагностика – V634. The priority of the '+' operation is higher than that of the '<<' operation. It's possible that parentheses should be used in the expression.
  • Новая диагностика – V635. Consider inspecting the expression. The length should probably be multiplied by the sizeof(wchar_t).

PVS-Studio 4.70 (4 июля 2012)

  • Добавлена поддержка Visual Studio 2012 RC. В настоящее время анализатор не полностью поддерживает все синтаксические конструкции, реализованные в Visual C++ 2012. Кроме того есть проблема со скоростью работы анализатора. Для повышения скорости работы мы используем препроцессор из Clang. В настоящее время Clang не полностью разбирает заголовочные файлы Visual C++ 2012. Поэтому в большинстве случаев будет использоваться препроцессор cl.exe из состава Visual C++, который работает существенно медленнее. Для пользователя выбор корректного препроцессора происходит автоматически и об этом не надо как-то специально заботиться. Несмотря на эти ограничения работать с PVS-Studio в Visual Studio 2012 RC уже можно.
  • Новая диагностика – V615. An odd explicit conversion from 'float *' type to 'double *' type.
  • Новая диагностика – V616. The 'Foo' named constant with the value of 0 is used in the bitwise operation.
  • Новая диагностика – V617. Consider inspecting the condition. An argument of the '|' bitwise operation always contains a non-zero value.
  • Новая диагностика – V618. It's dangerous to call the 'Foo' function in such a manner, as the line being passed could contain format specification. The example of the safe code: printf("%s", str);.
  • Новая диагностика – V619. An array is being utilized as a pointer to single object.
  • Новая диагностика – V620. It's unusual that the expression of sizeof(T)*N kind is being summed with the pointer to T type.
  • Новая диагностика – V621. Consider inspecting the 'for' operator. It's possible that the loop will be executed incorrectly or won't be executed at all.
  • Новая диагностика – V622. Consider inspecting the 'switch' statement. It's possible that the first 'case' operator in missing.
  • Новая диагностика – V623. Consider inspecting the '?:' operator. A temporary object is being created and subsequently destroyed.
  • Новая диагностика – V624. The constant NN is being utilized. The resulting value could be inaccurate. Consider using the M_NN constant from <math.h>.
  • Новая диагностика – V625. Consider inspecting the 'for' operator. Initial and final values of the iterator are the same.
  • Новая диагностика – V626. Consider checking for misprints. It's possible that ',' should be replaced by ';'.
  • Новая диагностика – V627. Consider inspecting the expression. The argument of sizeof() is the macro which expands to a number.
  • Новая диагностика – V628. It's possible that the line was commented out improperly, thus altering the program's operation logics.
  • Новая диагностика – V2006. Implicit type conversion from enum type to integer type.

PVS-Studio 4.62 (30 мая 2012)

  • Реализована возможность использования препроцессора MinGW gcc для проверки проектов, поддерживающих сборку компиляторами MinGW. При этом интеграция анализатора в сборочную систему подобного проекта аналогична использованию анализатора в других проектах без MSVC .sln-файлов, подробно описанному в документации. Стоит помнить, что при наличии у проекта .sln файлов, проверка из командной строки может быть выполнена и обычным способом, без необходимости прямой интеграции анализатора в сборочную систему.

PVS-Studio 4.61 (22 мая 2012)

  • Навигация для сообщений с несколькими номерами строк. Некоторые сообщения (например, V595) относятся к нескольким строкам кода. Раньше в окне PVS-Studio Output Window выдавался в столбце Line только один номер строки, а остальные строки указывались в тексте сообщения. Из-за этого навигация была затруднена. Теперь в поле Line могут выводиться несколько номеров строк, по которым возможно осуществлять навигацию.
  • Новая сборка Clang включена в дистрибутив. В PVS-Studio используется Clang в качестве препроцессора. В новой сборке исправлено несколько незначительных ошибок. Обратите внимание, что мы не используем Clang для диагностики ошибок.
  • Новая диагностика – V612. An unconditional 'break/continue/return/goto' within a loop.
  • Новая диагностика – V613. Strange pointer arithmetic with 'malloc/new'.
  • Новая диагностика – V614. Uninitialized variable 'Foo' used.

PVS-Studio 4.60 (18 апреля 2012)

  • Новая группа диагностических сообщений "Оптимизация" (OP) предлагает диагностику возможных оптимизаций. Это набор правил статического анализа для выявления участков кода в программах на языке C/C++/C++11, которые можно оптимизировать. Следует понимать, что статический анализатор решает задачи оптимизации в узкой нише микро-оптимизаций. Полный список диагностируемых ситуаций приведен в документации (коды V801-V807).
  • Существенно сокращено количество ложных срабатываний в анализаторе 64-битных ошибок (Viva64).
  • Теперь игнорируются ошибки в автогенерируемых файлах (MIDL).
  • Изменения в логике показа диалога сохранения отчета.
  • Исправлена работа на локализованной китайской версии Visual Studio (локаль zh).
  • Новая диагностика – V610. Undefined behavior. Check the shift operator.
  • Новая диагностика – V611. The memory allocation and deallocation methods are incompatible.

PVS-Studio 4.56 (14 марта 2012)

  • Добавлена опция TraceMode в Common Analyzer Settings. Настройка задаёт режим трассировки (протоколирования хода выполнения программы).
  • Исправлена ошибка при проверке Itanium-проектов.
  • Исправлена проблема вызова 64-битной версии clang.exe вместо 32-битной на 32-битной версии Windows при проверке проекта с выбранной платформой x64.
  • Изменено количество используемых при анализе ядер в инкрементальном режиме. Теперь для обычного анализа (Check solution/project/file) используется количество ядер, указанное в настройках. Для инкрементального анализа же используется другое количество ядер: если в настройках больше чем (количество ядер-1) и в системе несколько ядер, то (количество ядер-1); иначе – также как в настройках. Проще говоря, в инкрементальном анализе используется на одно ядро меньше, чтобы такой тип анализа не грузил систему.
  • Новая диагностика – V608. Recurring sequence of explicit type casts.
  • Новая диагностика – V609. Divide or mod by zero.

PVS-Studio 4.55 (28 февраля 2012)

  • Новое окно для продления триал-режима (без необходимости написания письма).
  • Исправлено падение при перезагрузке проекта во время работы анализатора кода.
  • В инсталляторе (при первой установке на машине) выдается запрос на включение инкрементального анализа в PVS-Studio. Если ранее PVS-Studio на машине уже устанавливалась, то запрос выдан не будет. Включить или выключить инкрементальный анализ можно также с помощью команды "Incremental Analysis after Build" в меню PVS-Studio.
  • Количество используемых ядер по умолчанию устанавливается как значение, равное количеству ядер минус один. Это можно изменить с помощью опции ThreadCount в настройках PVS-Studio.
  • Новая статья в документации: "Режим инкрементального анализа PVS-Studio".
  • Изменения в версии для командной строки – теперь возможна обработка нескольких файлов за один запуск PVS-Studio.exe по аналогии с компилятором (cl.exe file1.cpp file2.cpp). Раньше можно было в командной версии только один файл обрабатывать за раз. Подробнее об использовании версии для командной строки смотрите в документации.
  • Возможность проверки проектов Microsoft Visual Studio для ARMv4 архитектуры удалена.
  • Новая диагностика V604. It is odd that the number of iterations in the loop equals to the size of the pointer.
  • Новая диагностика V605. Consider verifying the expression. An unsigned value is compared to the number – NN.
  • Новая диагностика V606. Ownerless token 'Foo'.
  • Новая диагностика V607. Ownerless expression 'Foo'.

PVS-Studio 4.54 (1 февраля 2012)

  • Новый trial-режим. Теперь ограничиваются только клики. Подробности в блоге и в документации.
  • Новая команда меню "Disable Incremental Analysis until IDE restart". Иногда бывает полезно отключить инкрементальный анализ. Например, при редактировании базовых h-файлов, что приводит к перекомпиляции большого количества файлов. Но отключить не навсегда, ведь тогда его можно забыть включить, а временно. Команда также доступна в системном трее во время инкрементального анализа.
  • Новая диагностика V602. Consider inspecting this expression. '<' possibly should be replaced with '<<'.
  • Новая диагностика V603. The object was created but it is not being used. If you wish to call constructor, 'this->Foo::Foo(....)' should be used.
  • Новая диагностика V807. Decreased performance. Consider creating a pointer/reference to avoid using the same expression repeatedly.
  • Новая статья в документации: "Команды меню PVS-Studio".

PVS-Studio 4.53 (19 января 2012)

  • Новая команда для совместной (групповой) работы над кодом "Add TODO comment for Task List". PVS-Studio позволяет автоматически сгенерировать и внести в код комментарий TODO специального вида, содержащий всю необходимую информацию для оценки и анализа отмеченного им фрагмента программы. Такой комментарий будет сразу отображён в окне Task List в Visual Studio.
  • Новая диагностика V599. The virtual destructor is not present, although the 'Foo' class contains virtual functions.
  • Новая диагностика V600. Consider inspecting the condition. The 'Foo' pointer is always not equal to NULL.
  • Новая диагностика V601. An odd implicit type casting.

PVS-Studio 4.52 (28 декабря 2011)

  • Изменения в режиме работы анализатора из командной строки без использования .sln-файла. Теперь анализатор можно запускать в несколько процессов одновременно, выходной файл (--output-file) не будет потерян. Также в параметр --cl-params надо передавать всю строку параметров cl.exe вместе с именем файла: --cl-params $(CFLAGS) $**.
  • Исправлена ошибка "Analysis aborted by timeout", появляющаяся при проверке .sln-файла из командной строки через PVS-Studio.exe.
  • Новая диагностика V597. The compiler could delete the 'memset' function call, which is used to flush 'Foo' buffer. The RtlSecureZeroMemory() function should be used to erase the private data.
  • Новая диагностика V598. The 'memset/memcpy' function is used to nullify/copy the fields of 'Foo' class. Virtual method table will be damaged by this.

PVS-Studio 4.51 (21 декабря 2011)

  • Исправлена проблема, связанная с директивой #import при использовании Clang в качестве препроцессора. Clang не поддерживает #import так, как это реализовано в Microsoft Visual C++, поэтому использовать Clang для таких файлов нельзя. Это определяется автоматически и для подобных файлов запускается препроцессор Visual C++.
  • Существенно переделана настройка в PVS-Studio исключения из анализа файлов и папок Don't Check Files. Теперь отдельно указываются исключаемые папки (по короткому или полному пути или маске) и отдельно – исключаемые файлы (по имени, расширению или также маске).
  • Некоторые библиотеки добавлены в список исключаемых путей по умолчанию. Можно настроить на вкладке Don't Check Files.

PVS-Studio 4.50 (15 декабря 2011)

  • Для препроцессирования файлов в PVS-Studio используется внешний препроцессор. Раньше у нас использовался только один препроцессор от Microsoft Visual C++. В PVS-Studio 4.50 появилась поддержка второго препроцессора Clang, который работает существенно быстрее и лишен ряда недостатков препроцессора от Microsoft (хотя и имеет свои недостатки). Тем не менее, в большинстве случаев использование препроцессора Clang позволяет повысить скорость работы в 1.5-1.7 раз. Однако здесь есть нюанс, который надо учитывать. Указать используемый препроцессор можно в настройках PVS-Studio Options -> Common Analyzer Settings -> Preprocessor. Доступны варианты: VisualCPP, Clang и VisualCPPAfterClang. Первые два варианта очевидны, а третий вариант означает, что сначала будет использоваться Clang, в случае если при препроцессировании будут ошибки, то затем файл будет заново препроцессирован с помощью Visual C++. По умолчанию выбрана именно эта опция (VisualCPPAfterClang).
  • Анализатор по умолчанию не выдает диагностические сообщения на библиотеки zlib и libpng (это можно отключить).
  • Новая диагностика V596. The object was created but it is not being used. The 'throw' keyword could be missing.

PVS-Studio 4.39 (25 ноября 2011)

  • Добавлены новые диагностические правила (V594, V595).
  • Анализатор по умолчанию не выдает диагностические сообщения на библиотеку Boost (это можно отключить).
  • При инкрементальном анализе не выводится диалог прогресса, вместо него в трее показывается иконка, с помощью которой можно сделать паузу или прервать анализ.
  • В контекстном меню результатов анализа появилась команда "Don't Check Files and hide all messages from ...". С её помощью можно удалить сообщения и в дальнейшем не проверять файлы из определенной папки. Список исключенных папок можно посмотреть в настройках Don't Check Files.
  • Улучшено определение использования Intel C++ Compiler - PVS-Studio не работает с проектами, которые собираются этим компилятором, нужно сменить компилятор на Visual C++.
  • Добавлена функция "Quick Filters", позволяющая фильтровать все сообщения, не удовлетворяющие заданным фильтрам.

PVS-Studio 4.38 (12 октября 2011)

  • Повышена скорость работы анализатора (примерно на 25% для четырехъядерных машин).
  • В контекстное меню окна PVS-Studio добавлена команда перехода по ID ("Navigate to ID").
  • Новое окно "Find in PVS-Studio Output" позволяет осуществлять поиск по ключевым словам в результатах анализа.
  • Добавлены новые диагностические правила (V2005).
  • Кнопка Options переименована в Suppression, и в ней только три вкладки.

PVS-Studio 4.37 (20 сентября 2011)

  • Добавлены новые диагностические правила (V008, V2003, V2004).
  • Появилась возможность экспортировать результаты анализа в текстовый файл.
  • Теперь мы используем расширенный номер сборки в некоторых случаях.

PVS-Studio 4.36 (31 августа 2011)

  • Добавлены новые диагностические правила (V588, V589, V590, V591, V592, V593).

PVS-Studio 4.35 (12 августа 2011)

  • Добавлены новые диагностические правила (V583, V584, V806, V585, V586, V587).

PVS-Studio 4.34 (29 июля 2011)

  • 64-битный анализ по умолчанию отключен.
  • Инкрементальный анализ по умолчанию включен.
  • Изменения в поведении в ознакомительном режиме.
  • Появился предопределенный макрос PVS_STUDIO.
  • Исправлена проблема с инкрементальным анализом на локализованных версиях Visual Studio.
  • Всплывающие уведомления и иконка в трее добавлены (по завершении анализа).
  • Добавлены новые диагностические правила (V582).
  • Изменена картинка для показа с левой стороны мастера установки в дистрибутиве.

PVS-Studio 4.33 (21 июля 2011)

  • Режим работы "Incremental Analysis" теперь доступен во всех версиях Microsoft Visual Studio (2005/2008/2010), а не только в VS2010.
  • Повышена скорость работы анализатора (примерно на 20% для четырехъядерных машин).
  • Добавлены новые диагностические правила (V127, V579, V580, V581).

PVS-Studio 4.32 (15 июля 2011)

  • Изменения в лицензионной политике PVS-Studio.
  • Реализована динамическая балансировка загрузки процессора.
  • Кнопка останова анализа работает быстрее.

PVS-Studio 4.31 (6 июля 2011)

  • Исправлена проблема взаимодействия с некоторыми плагинами, включая Visual Assist.
  • Добавлены новые диагностические правила (V577, V578, V805).

PVS-Studio 4.30 (23 июня 2011)

  • Появилась полноценная поддержка работы анализатора из командной строки. Можно проверять отдельные файлы или группы файлов, вызывая анализатор из Makefile. При этом сообщения анализатора можно видеть не только на экране (для каждого файла), но и записать в один файл, который в дальнейшем можно открыть в Visual Studio и уже получить полноценную работу с результатами анализа: настройки кодов ошибок, фильтры сообщений, навигация по коду, сортировка и т.п. Подробнее.
  • Новый важный режим работы Incremental Analysis. PVS-Studio теперь может автоматически запускать анализ измененных файлов, которые надо пересобрать с помощью команды Build в Visual Studio. Теперь все разработчики команды могут сразу же видеть проблемы в новом только что написанном коде без необходимости явно запускать проверку кода – это происходит автоматически. Incremental Analysis работает подобно IntelliSense в Visual Studio. Возможность доступна только в Visual Studio 2010. Подробнее.
  • Добавлена команда "Check Selected Item(s)".
  • Изменения в запуске команды "Check Solution" при старте из командной строки. Подробнее.
  • Добавлены новые диагностические правила (V576).

PVS-Studio 4.21 (20 мая 2011)

  • Добавлены новые диагностические правила (V220, V573, V574, V575).
  • Добавлена поддержка TFS 2005/2008/2010.

PVS-Studio 4.20 (29 апреля 2011)

  • Добавлены новые диагностические правила (V571, V572).
  • Добавлена экспериментальная поддержка архитектур ARMV4/ARMV4I для Visual Studio 2005/2008 (Windows Mobile 5/6, PocketPC 2003, Smartphone 2003).
  • Новая опция "Show License Expired Message".

PVS-Studio 4.17 (15 апреля 2011)

  • Добавлены новые диагностические правила (V007, V570, V804).
  • Исправлено неправильное отображение времени анализа файлов при некоторых настройках локали.
  • Новая опция "Analysis Timeout". Данная настройка позволяет задать лимит времени, по истечении которого анализ отдельных файлов завершается с ошибкой V006, или совсем отключить прерывание анализа по лимиту времени.
  • Новая опция " Save File After False Alarm Mark". Сохранять или нет файл каждый раз после пометки как False Alarm.
  • Новая опция " Use Solution Folder As Initial". Определяет папку, которая открывается при сохранении файла с результатами анализа.

PVS-Studio 4.16 (1 апреля 2011)

  • При запуске инструмента из командной строки теперь можно задать список файлов, которые будут проверяться. Это можно использовать для проверки, к примеру, только тех файлов, которые были обновлены в системе контроля версий. Подробнее.
  • В настройки инструмента добавлена опция "Check only Files Modified In". Данное поле позволяет задать временной интервал, для которого будет осуществляться проверка наличия изменений в анализируемых файлах с использованием файлового атрибута "Date Modified". Другими словами, такой подход позволит проверять "все файлы, которые были изменены за последний день". Подробнее.

PVS-Studio 4.15 (17 марта 2011)

  • Значительно уменьшено количество ложных срабатываний для 64-битного анализа.
  • Изменения в интерфейсе задания безопасных типов (safe-types).
  • Исправлена ошибка с обработкой stdafx.h в некоторых особых случаях.
  • Улучшена работа с файлом отчета.
  • Улучшен диалог прогресса: показывается затраченное время и сколько осталось.

PVS-Studio 4.14 (2 марта 2011)

  • Значительно уменьшено количество ложных срабатываний для 64-битного анализа.
  • Добавлены новые диагностические правила (V566, V567, V568, V569, V803).
  • В окне сообщений PVS-Studio появилась новая колонка "Звездочка". Теперь вы можете отметить интересные диагностики звездочкой для того, чтобы в дальнейшем обсудить их с коллегами. Пометки сохраняются в файл отчета.
  • Опции PVS-Studio теперь доступны не только из меню (в обычном диалоге настроек), но и в окне PVS-Studio. Благодаря этому настройка инструмента теперь делается быстрее и удобнее.
  • Добавлена возможность сохранять и восстанавливать настройки PVS-Studio. Это позволяет переносить настройки между различными компьютерами и рабочими местами. Также появилась команда "Восстановить настройки по умолчанию".
  • Добавлено сохранение статус кнопок окна PVS-Studio (включено/выключено) при следующем запуске Microsoft Visual Studio.

PVS-Studio 4.13 (11 февраля 2011)

  • Добавлены новые диагностические правила (V563, V564, V565).
  • Команда "Check for updates" добавлена в меню PVS-Studio.
  • Команда "Hide all VXXX errors" для выключения ошибок по их коду добавлена в контекстное меню окна PVS-Studio. Если вы хотите включить обратно показ диагностик VXXX вы можете сделать это через страницу настроек PVS-Studio->Options->Detectable errors.
  • Подавление ложных предупреждений в макросах (#define) добавлено.

PVS-Studio 4.12 (7 февраля 2011)

  • Добавлены новые диагностические правила (V006, V204, V205, V559, V560, V561, V562).
  • Изменения в диагностических правилах V201 и V202.

PVS-Studio 4.11 (28 января 2011)

  • Диагностическое правило V401 заменено на V802.
  • Исправлена проблема с копированием сообщений в буфер обмена.

PVS-Studio 4.10 (17 января 2011)

  • Добавлены новые диагностические правила (V558).

PVS-Studio 4.00 (24 декабря 2010)

  • Добавлены новые диагностические правила (V546-V557).
  • Исправлена проблема с обработкой property sheets в Visual Studio 2010.
  • Исправлена ошибка с обходом дерева проектов.
  • В окно PVS-Studio добавлено поле "Project" - проект, к которому относится диагностическое сообщение.
  • Исправлена установка PVS-Studio для Visual Studio 2010 – теперь PVS-Studio устанавливается для всех пользователей, а не только для текущего.
  • Исправлено падение при попытке сохранить пустой файл отчета.
  • Исправлена проблема с отсутствующим файлом safe_types.txt.
  • Исправлена ошибка, возникающая при попытке проверить файлы, которые включены в проект, но реально на диске не существуют (например, это автогенерируемые файлы).
  • Добавлена индикация процесса обработки дерева проекта.
  • Файл с результатами анализа PVS-Studio (расширение .plog) теперь загружается по двойному клику.
  • Изменения в лицензионной политике.

PVS-Studio 4.00 BETA (24 ноября 2010)

  • Новый набор правил статического анализа общего назначения (V501-V545, V801).
  • Добавлены новые правила (V124-V126).
  • Изменения в лицензионной политике.
  • Новое окно для диагностических сообщений, выдаваемых анализатором.
  • Повышение скорости работы.

PVS-Studio 3.64 (28 сентября 2010)

  • Существенное обновление документации по PVS-Studio, добавлены новые разделы.

PVS-Studio 3.63 (10 сентября 2010)

  • Исправлена проблема, иногда возникающая при анализе файлов с не системного диска.
  • Исправлена проблема с вычислением значений макросов для отдельных файлов (а не всего проекта).
  • Команда "What Is It?" удалена.
  • Демонстрационные примеры проблем 64-битного кода (PortSample) и параллельного кода (ParallelSample) объединены в единый пример OmniSample, который подробно описан в документации.
  • Исправлено падение при наличии в решении выгруженного (unloaded) проекта.

PVS-Studio 3.62 (16 августа 2010)

  • Добавлено новое правило V123: Allocation of memory by the pattern "(X*)malloc(sizeof(Y))" where the sizes of X and Y types are not equal.
  • Упрощена работа с PVS-Studio из командной строки (без файла проекта Visual Studio).
  • По умолчанию не выдаются сообщения об ошибках в tli/tlh файлах.

PVS-Studio 3.61 (22 июля 2010)

  • Исправлено падение в VS2010 при выставленном параметре EnableAllWarnings в настройках проекта.
  • Исправлена ошибка – проверялись даже те проекты, которые были исключены из сборки в Configuration Manager.
  • Улучшен анализ кода.

PVS-Studio 3.60 (10 июня 2010)

  • Добавлено новое правило V122: Memsize type is used in the struct/class.
  • Добавлено новое правило V303: The function is deprecated in the Win64 system. It is safer to use the NewFOO function.
  • Добавлено новое правило V2001: Consider using the extended version of the FOO function here.
  • Добавлено новое правило V2002: Consider using the 'Ptr' version of the FOO function here.

PVS-Studio 3.53 (7 мая 2010)

  • Добавлена возможность задать вопрос разработчикам PVS-Studio про сообщения, выдаваемые анализатором кода (команда "What Is It").
  • Значительно улучшен анализ кода, связанного с использованием неименованных структур.
  • Исправлена ошибка, приводившая в некоторых случаях к неверному вычислению размера структур.

PVS-Studio 3.52 (27 апреля 2010)

  • Добавлена новая online справочная система. Старая справочная система интегрировалась в MSDN. По некоторым причинам это неудобно (как пользователям, так и разработчикам). Теперь PVS-Studio будет открывать справку на нашем сайте. От интеграции с MSDN мы отказались. И, как и прежде, доступна pdf-версия документации.
  • Отказались от поддержки Windows 2000.
  • Удалена страница настроек "Exclude From Analysis" - вместо нее страница "Don't Check Files".
  • Улучшена работа в Visual Studio 2010.
  • Исправлена проблема с интеграцией в VS2010 при повторной инсталляции.
  • Исправлена работа функции "Mark As False Alarm" с read-only файлами.

PVS-Studio 3.51 (16 апреля 2010)

  • PVS-Studio поддерживает работу в Visual Studio 2010 RTM.
  • Добавлено новое правило V003: Unrecognized error found...
  • Добавлено новое правило V121: Implicit conversion of the type of 'new' operator's argument to size_t type.
  • Добавлена возможность исключить из анализа файлы по маске (PVS-Studio Options, вкладка Don't Check Files).
  • Переделан интерфейс страницы настроек Exclude From Analysis.
  • Убрана опция MoreThan2Gb из страницы настроек Viva64 (опция устарела и более не имеет смысла).
  • При проверке кода из командной строки надо указывать тип анализатора (Viva64 или VivaMP).
  • Снижен приоритет процесса анализатора, что позволяет комфортно работать на машине во время проверки кода.

PVS-Studio 3.50 (26 марта 2010)

  • PVS-Studio поддерживает работу в Visual Studio 2010 RC. Хотя официальный выпуск Visual Studio еще не состоялся, мы уже добавили поддержку этой среды в анализатор. Сейчас PVS-Studio интегрируется в Visual Studio 2010 и может проверять проекты в этой среде. В Visual Studio 2010 изменена справочная система, поэтому пока справка от PVS-Studio не интегрируется в документацию, как это делается в Visual Studio 2005/2008. Но вы по-прежнему можете пользоваться online-справкой. Поддержка Visual Studio 2010 RC реализована не полностью.
  • Доступна PDF-версия справочной системы. Теперь в дистрибутиве с PVS-Studio идет 50-страничный PDF-документ. Это полная копия нашей справочной системы (которая интегрируется в MSDN в Visual Studio 2005/2008 или доступна online).
  • В PVS-Studio появился механизм автоматического определения новых версий инструмента на нашем сайте. Определение новых версий контролируется через опцию CheckForNewVersions вкладки настроек "Common Analyzer Settings". В случае если опция CheckForNewVersions имеет значения True, то при запуске проверки кода (команды Check Current File, Check Current Project, Check Solution меню PVS-Studio) выполняется загрузка специального текстового файла с сайта www.viva64.com. В этом файле прописан номер самой последней версии PVS-Studio, доступной на сайте. Если версия на сайте окажется новее, чем версия, установленная у пользователя, то пользователь увидит запрос на обновление. В случае разрешения этого обновления запустится специальное отдельное приложение PVS-Studio-Updater, которое автоматически загрузит новый дистрибутив PVS-Studio с сайта и запустит его установку. В случае если опция CheckForNewVersions установлена в False, то проверка новой версии производиться не будет.
  • Реализована поддержка стандарта C++0x на уровне, на котором она осуществлена в Visual Studio 2010. Реализована поддержка лямбда-выражений, auto, decltype, static_assert, nullptr и так далее. В дальнейшем, с развитием поддержки C++0x в Visual C++, анализатор PVS-Studio также будет поддерживать новые возможности языка Си++.
  • Стало возможно запускать проверку проектов с помощью PVS-Studio не из Visual Studio, а с помощью командой строки. Обратите внимание, что речь идет все равно о проверке из Visual Studio с использованием файлов проектов (.vcproj) и решений (.sln), но при этом запуск анализа будет осуществляться не из IDE, а из командной строки. Такой вариант запуска удобен для регулярной проверки кода с помощью систем сборки (build system) или систем непрерывной интеграции (continuous integration system).
  • Добавлено новое правило V1212: Data race risk. When accessing the array 'foo' in a parallel loop, different indexes are used for writing and reading.
  • В этой версии инструмента мы ввели сертификат подписи кода. Это позволит пользователям быть уверенным в подлинности дистрибутива и получать меньше сообщений от операционной системы при установке приложения.

PVS-Studio 3.45 (1 февраля 2010)

  • Существенно улучшена работа анализатора с шаблонами.
  • Улучшена работа на многоядерных системах.

PVS-Studio 3.44 (21 января 2010)

  • Частичная поддержка проверки кода для процессоров Itanium. Теперь код, который собирается в Visual Studio Team System для процессоров Itanium также можно проверять с помощью анализатора. Анализ выполняется на системах x86 и x64, запуск на Itanium пока не реализован.
  • Сокращение количества ложных срабатываний анализатора при анализе доступа к массивам. Теперь анализатор в ряде случаев "понимает" диапазоны значений в цикле for и не выводит лишних сообщений про доступе к массивам с помощью таких индексов. Например: for (int i = 0; i < 8; i++) arr[i] = foo(); // нет сообщения анализатора.
  • Сокращенено количество ложных сообщений анализатора - введен список типов данных, которые не образуют большие массивы. Например, HWND, CButton. Пользователь может составлять свои списки типов.
  • Исправлена ошибка в работе инсталятора при установке программы в папку, отличную от папки по умолчанию.

PVS-Studio 3.43 (28 декабря 2009)

  • Удалена опция ShowAllErrorsInString (теперь она всегда имеет значение true).
  • Новое правило V120: Member operator[] of object 'foo' declared with 32-bit type argument, but called with memsize type argument.
  • Новое правило V302: Member operator[] of 'foo' class has a 32-bit type argument. Use memsize-type here.
  • Улучшен анализ operator[].
  • Исправлена ошибка с долгим удалением программы при многократной установке "поверх".
  • Исправлена ошибка анализа файлов с символом "^" в имени.

PVS-Studio 3.42 (9 декабря 2009)

  • Улучшена диагностика ошибок с магическими числами. Теперь в сообщении о проблеме выдается больше информации, что позволяет более гибко использовать фильтры.
  • Исправлена ошибка при работе с прекомпилированными заголовочными файлами специального типа.
  • Опция DoTemplateInstantiate (выполнять инстанцирования шаблонов) теперь по умолчанию включена.
  • Исправлена ошибка с зависанием препроцессора при большом количестве сообщений препроцессора.
  • Улучшен анализ operator[].

PVS-Studio 3.41 (30 ноября 2009)

  • Исправлена ошибка анализа файлов с одинаковыми именами при работе на многоядерной машине.
  • Исправлена ошибка некорректной диагностики некоторых типов cast-выражений.
  • Существенно улучшен разбор перегруженных функций в анализаторе.
  • Добавлена диагностика некорректного использования time_t типа.
  • Добавлена обработка специальных параметров в настройках файлов проекта Visual C++.

PVS-Studio 3.40 (23 ноября 2009)

  • Добавлена возможность "Mark as False Alarm". Благодаря этому возможно пометить в исходном коде те строки, в которых происходит ложное срабатывание анализатора кода. После разметки, анализатор более не будет выдавать диагностических сообщений на такой код. Это позволяет более удобно постоянно использовать анализатор в процессе разработки программного обеспечения для проверки нового кода.
  • Добавлена поддержка Project Property Sheets - механизма удобной настройки проектов Visual Studio.
  • При проверке параллельных программ анализатор может выполнять два прохода по коду, что позволяет собрать больше информации и выполнить более точную диагностику некоторых ошибок.

PVS-Studio 3.30 (25 сентября 2009)

  • В PVS-Studio добавлена возможность проверки 32-битных проектов для оценки сложности и стоимости миграции кода на 64-битные системы.
  • Добавлено новое правило для анализа 64-битного кода V118: malloc() function accepts a dangerous expression in the capacity of an argument.
  • Добавлено новое правило для анализа 64-битного кода V119: More than one sizeof() operators are used in one expression.
  • Добавлено новое правило для анализа параллельного кода V1211: The use of 'flush' directive has no sense for private '%1%' variable, and can reduce performance.
  • Улучшена совместная работа с Intel C++ Compiler (исправлено падение при попытке проверки кода с установленным Intel C++ Compiler).
  • Улучшена поддержка локализованных версий Visual Studio.

PVS-Studio 3.20 (7 сентября 2009)

  • Исправлена ошибка с некорректным выводом некоторых сообщений в локализованных версиях Visual Studio.
  • Улучшена загрузка log-файла.
  • Улучшена обработка критических ошибок - теперь о возможных проблемах с инструментов сообщить нам стало просто.
  • Улучшена работа инсталлятора.
  • Исправлена ошибка перебора файлов проекта.

PVS-Studio 3.10 (10 августа 2009)

  • Добавлена поддержка инстанцирования шаблонов. Теперь поиск потенциальных ошибок выполняется не просто по телу шаблонов (как ранее), но и еще выполняется подстановка аргументов шаблона для более тщательной диагностики.
  • Теперь анализатор кода может работать в режиме имитации Linux-окружения. Мы добавили поддержку различных моделей данных. Поэтому теперь на Windows-системе можно проверять кросс-платформенные программы также, как это делалось бы на Linux-системе.
  • Исправлена ошибка, связанная с некорректной работой анализатора параллельных ошибок в 32-битном окружении.
  • Существенно улучшена работа анализатора с шаблонами.

PVS-Studio 3.00 (27 июля 2009)

  • Программные продукты Viva64 и VivaMP объединены в один программный комплекс PVS-Studio.
  • Новая версия представляет собой существенно модернизированный программный продукт.
  • Существенно повышена стабильность работы модуля интеграции в Visual Studio.
  • Повышена скорость работы на многопроцессорных системах: анализ выполняется в несколько потоков. Причем количество рабочих потоков анализатора можно настраивать с помощью опции "Thread Count". По умолчанию количество потоков соответствует количеству ядер в процессоре, однако количество потоков можно уменьшить.
  • Добавлена возможность работы анализатора из командной строки. В настройки программы добавлена новая опция "Remove Intermediate Files" ("Удалять промежуточные файлы"), которая позволяет не удалять командные файлы, создаваемые во время работы анализатора кода. Эти командные файлы можно запускать отдельно, без Visual Studio для выполнения анализа. Кроме того, создавая новые командные файлы по аналогии можно выполнять анализ всего проекта без использования Visual Studio.
  • Управлять диагностикой отдельных ошибок стало проще, удобнее и быстрее. Теперь можно включать и выключать показ отдельных ошибок в результатах анализа. Самое главное, что изменение списка сообщений происходит автоматически, без необходимости перезапуска анализа. Выполнив анализ, вы можете просмотреть список ошибок и просто выключить показ тех из них, которые для вашего проекта не актуальны.
  • Значительно улучшена работа с фильтрами ошибок. Фильтры для сокрытия отдельных сообщений теперь задаются просто как список строк. Причем применение фильтров также как и управление диагностикой отдельных ошибок не требует перезапуска анализа.
  • Изменение лицензионной политики. Хотя PVS-Studio является единым продуктом, лицензирование возможно и для отдельных модулей анализа, таких как Viva64 и VivaMP, и для всех модулей сразу. Кроме того, появились лицензии для одного пользователя и для команды разработчиков. Все эти изменения нашли отражение в регистрационных ключах.
  • Поддержка локализованных версий Visual Studio существенно улучшена.
  • Интегрирующаяся в MSDN справочная система для новой версии PVS-Studio была значительно переработана и усовершенствована. Описание новых разделов позволяет лучше изучить работу с программным продуктом.
  • Улучшено графическое оформление программного продукта. Новые иконки и графика в инсталляторе придали анализатору более красивый вид.

VivaMP 1.10 (20 апреля 2009)

  • Улучшен анализ кода, содержащего вызовы статических функций класса.
  • Реализованы новые диагностические правила для анализа ошибок связанных с исключениями: V1301, V1302, V1303.
  • Исправлена ошибка с некорректным отображением индикатора прогресса анализа на компьютерах с нестандартным DPI.
  • Реализованы некоторые другие усовершенствования.

VivaMP 1.00 (10 марта 2009)

  • Выпущена финальная версия VivaMP.

VivaMP 1.00 beta (27 ноября 2008)

  • Первая публичная бета-версия VivaMP выложена в Интернете.

Viva64 2.30 (20 апреля 2009)

  • Реализовано новое диагностическое правило V401.
  • Улучшена обработка констант, что в ряде случаев сокращает количество ложных диагностических предупреждений.
  • Исправлена ошибка с некорректным отображением индикатора прогресса анализа на компьютерах с нестандартным DPI.
  • Исправлен ряд недочетов.

Viva64 2.22 (10 марта 2009)

  • Улучшена совместная работа Viva64 и VivaMP.
  • Увеличена скорость работы анализатора кода на 10%.

Viva64 2.21 (27 ноября 2008)

  • Добавлена поддержка совместной работы Viva64 и VivaMP.

Viva64 2.20 (15 октября 2008)

  • Улучшена диагностика потенциально опасных конструкций. В результате примерно на 20% сократилось количество "ложных срабатываний" анализатора кода. Теперь разработчик потратит меньше времени на анализ кода, диагностируемого как потенциально опасный.
  • Изменения в справочной системе. Справка было расширена и дополнена новыми примерами. Так как в данной версии улучшена диагностика потенциально опасных конструкций, то в справочную систему также были добавлены пояснения, касающиеся того, какие конструкции теперь не считаются опасными.
  • Увеличена скорость анализа структуры проекта. Теперь же такая работа выполняется примерно в 10 раз быстрее. В конечном итоге это сокращает общее время анализа всего проекта.
  • Улучшен анализ шаблонов в языке Си++. Не секрет, что далеко не все анализаторы кода полностью понимают шаблоны (template). Мы постоянно работаем над улучшением диагностики потенциально опасных конструкций в шаблонах. Очередное подобное улучшение сделано в этой версии.
  • Изменен формат ряда сообщений анализатора кода для возможности осуществления более тонкой настройки фильтров. Так, например, теперь анализатор не просто сообщает о некорректном типе индекса при доступе к массиву, но при этом и указывает имя самого массива. Если разработчик уверен, что подобный массив никак не может быть источником проблем для 64-битного режима работы, то он может отфильтровать все сообщения, относящиеся к данному массиву по его имени.

Viva64 2.10 (05 сентября 2008)

  • Добавлена поддержка Visual C++ 2008 Service Pack 1.

Viva64 2.0 (09 июля 2008)

  • Добавлена поддержка Visual C++ 2008 Feature Pack (и TR1).
  • Добавлен режим Pedantic, позволяющий в случае необходимости находить конструкции, представляющие потенциальную опасность, но редко приводящие к ошибкам.
  • Улучшена диагностика шаблонных функций.

Viva64 1.80 (03 февраля 2008)

  • Visual Studio 2008 полностью поддерживается.
  • Увеличена скорость анализа кода.
  • Улучшен установщик. Теперь возможно установить Viva64 без прав администратора.

Viva64 1.70 (20 декабря 2007)

  • Добавлена поддержка нового диагностического сообщения (V117). Memsize type used in union.
  • Исправлена серьезная проблема связанная с диагностикой нескольких ошибок в одной строке кода.
  • Исправлена ошибка вычисления типов в сложных синтаксических конструкциях.
  • Улучшен интерфейс пользователя. Индикатор прогресса отслеживает анализ всего решения (solution).
  • Visual Studio 2008 частично поддерживается(BETA).

Viva64 1.60 (28 августа 2007)

  • Добавлена поддержка нового диагностического сообщения (V112). Dangerous magic number used.
  • Добавлена поддержка нового диагностического сообщения (V115). Memsize type used for throw.
  • Добавлена поддержка нового диагностического сообщения (V116). Memsize type used for catch.
  • Изменены ограничения ознакомительной версии. Для каждого анализируемого файла показываются только несколько диагностических сообщений.

Viva64 1.50 (15 мая 2007)

  • Добавлена поддежка анализа кода на языке Си.

Viva64 (1.40 - 1 мая 2007)

  • Добавлена возможность подавления некоторых сообщений. Вы можете задавать свои фильтры на странице настроек "Message Suppression". Например, вы можете захотеть пропускать сообщения с определенным кодом ошибки или сообщения, содержащие определенные имена функций. (См. Settings: Message Suppression).
  • Появилась возможность сохранять/загружать результаты анализа..
  • Улучшено представление результатов работы анализатора. Результаты теперь выдаются в стандартном окне Visual Studio под названием Error List, подобно сообщениям компилятора.

Viva64 1.30 (17 марта 2007)

  • Улучшено представление процесса анализа кода. Убраны лишние переключения окон, создан общий индикатор прогресса.
  • Добавлена панель инструментов Viva64.
  • Пользователь может указать анализатору, что проверяемая программа может использовать более 2Гб оперативной памяти. Для программ, использующих меньше 2Гб памяти некоторые диагностические сообщения будут отключены.
  • Добавлена поддержка нового диагностического сообщения (V113). Implicit type conversion from memsize to double type or vice versa.
  • Добавлена поддержка нового диагностического сообщения (V114). Dangerous explicit type pointer conversion.
  • Добавлена поддержка нового диагностического сообщения (V203). Explicit type conversion from memsize to double type or vice versa.

Viva64 1.20 (26 января 2007)

  • Добавлена фильтрация повторяющихся сообщений. Речь идет об ошибках в h-файлах. Ранее если *.h файл с ошибкой включался в различные *.cpp файлы, то диагностические сообщения выдавались несколько раз. Теперь же будет только одно диагностическое сообщение.
  • Теперь Viva64 сообщает о количестве ошибок, обнаруженных после анализа кода. Вы всегда можете определить: - сколько кода осталось проверить; - как много ошибок уже исправлено; - какие модули содержат наибольшее количество ошибок.
  • Добавлена поддержка горячих клавиш. Теперь можно прервать работу анализатора с помощью Ctrl+Break. А для проверки текущего файла достаточно нажать Ctrl+Shift+F7.
  • Исправлены некоторые ошибки в работе анализатора.

Viva64 1.10 (16 января 2007)

  • С помощью анализатора Viva64 мы подготовили 64-битную версию Viva64! Но пользователю не надо беспокоиться о выборе подходящей версии. Правильная версия выбирается автоматически во время установки.
  • Добавлена поддержка нового диагностического сообщения (V111).
  • Удалена ненужная диагностика на доступ к массивам с помощью enum-значений.
  • Удалена ненужная диагностика ошибок на конструкции вида int a = sizeof(int).
  • Улучшения справочной системы.

Viva64 1.00 (31 декабря 2006)

  • Первая публичная версия Viva64 выложена в Интернете.

Как запустить PVS-Studio Java

Статический анализатор кода PVS-Studio Java состоит из 2-х основных частей: ядра, выполняющего анализ и плагинов для интеграции в сборочные системы и IDE.

Плагины получают структуру проекта (наборы исходных файлов и classpath), после чего передают эту информацию в ядро. Кроме того, плагины отвечают за развёртывание ядра для анализа - оно будет автоматически скачано при первом запуске.

Анализатор имеет несколько различных способов интеграции в проект.

Системные требования

  • Операционная система: Windows, Linux, macOS;
  • Минимальная версия Java для запуска анализатора: Java 8 (64-битная). Примечание: Анализируемый проект может использовать любую версию Java;
  • Минимальная версия IntelliJ IDEA: 2017.2 (опционально);

Плагин для Maven

Для проектов со сборочной системой Maven можно воспользоваться плагином pvsstudio-maven-plugin. Для этого необходимо добавить следующее в файл pom.xml:

<pluginRepositories>
  <pluginRepository>
    <id>pvsstudio-maven-repo</id>
    <url>http://files.viva64.com/java/pvsstudio-maven-repository/</url>
  </pluginRepository>
</pluginRepositories>

<build>
  <plugins>
    <plugin>
      <groupId>com.pvsstudio</groupId>
      <artifactId>pvsstudio-maven-plugin</artifactId>
      <version>7.09.41421</version>
      <configuration>
        <analyzer>
          <outputType>text</outputType>
          <outputFile>path/to/output.txt</outputFile>
        </analyzer>
      </configuration>
    </plugin>
  </plugins>
</build>

После этого можно запустить анализ:

$ mvn pvsstudio:pvsAnalyze

Кроме того, анализ можно включить в цикл сборки проекта, добавив элемент execution:

<plugin>
  <groupId>com.pvsstudio</groupId>
  <artifactId>pvsstudio-maven-plugin</artifactId>
  <version>7.09.41421</version>
  <executions>
    <execution>
      <phase>compile</phase>
      <goals>
        <goal>pvsAnalyze</goal>
      </goals>
    </execution>
  </executions>
</plugin>

Ввод лицензии

Чтобы ввести данные лицензии можно воспользоваться следующей командой:

mvn pvsstudio:pvsCredentials "-Dpvsstudio.username=USR" "-Dpvsstudio.serial=KEY"

После этого информация о лицензии будет сохранена в %APPDATA%/PVS-Studio-Java/PVS-Studio.lic в ОС Windows или в ~/.config/PVS-Studio-Java/PVS-Studio.lic в macOS и Linux.

Конфигурация

В блоке <analyzer> производится настройка анализатора. Ниже представлен список настроек анализатора.

  • <outputFile>PATH</outputFile> - путь до файла с отчетом анализатора. Значение по умолчанию: ${basedir}/PVS-Studio. Примечание: для отчета в формате 'fullhtml' в outputFile необходимо указать директорию, в которой будет создана папка с именем 'fullhtml' с отчетом анализатора. Значение по умолчанию: ${basedir}/fullhtml;
  • <outputType>TYPE</outputType> - формат отчета анализатора (text, log, json, xml, tasklist, html, fullhtml, errorfile). Значение по умолчанию: json;
  • <threadsNum>NUMBER</threadsNum> - число потоков анализа. Значение по умолчанию: число доступных процессоров;
  • <sourceTreeRoot>PATH</sourceTreeRoot> - общий корневой путь до исходников, который будет использоваться для генерации отчёта анализатора с относительными путями до проверяемых исходных файлов. Значение по умолчанию отсутствует;
  • <enabledWarnings>V6XXX, ....</enabledWarnings> - список активных диагностик. При задании включённых диагностик, не указанные здесь будут отключены. Значение по умолчанию отсутствует. При отсутствии значения данного параметра все диагностики считаются включенными (если дополнительно не задан параметр disabledWarnings);
  • <disabledWarnings>V6XXX, ....</disabledWarnings> - список выключенных диагностик. При задании отключённых диагностик, не указанные здесь будут считаться включёнными. Значение по умолчанию отсутствует. При отсутствии данного параметра все диагностики считаются включёнными (если дополнительно не задан параметр enabledWarnings)
  • <exclude>PATH, ....</exclude> - список файлов и/или директорий, которые нужно исключить из анализа (абсолютные или относительные пути). Значение по умолчанию отсутствует. При отсутствии данного параметра будут проанализированы все файлы (если дополнительно не задан параметр analyzeOnly);
  • <analyzeOnly>PATH, ....</analyzeOnly> - список файлов и/или директорий, которые нужно проанализировать (абсолютные или относительный пути). Значение по умолчанию отсутствует. При отсутствии данного параметра будут проанализированы все файлы (если дополнительно не задан параметр exclude);
  • <suppressBase>PATH</suppressBase> - путь до suppress файла, содержащего подавленные сообщения анализатора, которые не будут выданы в отчёте об анализе. Добавить сообщения в suppress файл можно через интерфейс PVS-Studio IDE плагина для IntelliJ IDEA. Значение по умолчанию: ${basedir}/.PVS-Studio/suppress_base.json;
  • <failOnWarnings>BOOLEAN</failOnWarnings> - прерывать ли сборку, если анализатор выдал какое-либо предупреждение. Значение по умолчанию: false;
  • <incremental>BOOLEAN</incremental> - запускать ли анализ инкрементально (в этом режиме анализируются только изменившиеся файлы). Значение по умолчанию: false;
  • <forceRebuild>BOOLEAN</forceRebuild> - флаг, позволяющий принудительно перестроить целиком закэшированную метамодель программы, содержащую информацию о её структуре и типах данных. Значение по умолчанию: false.
  • <disableCache>BOOLEAN</disableCache> - флаг, позволяющий отключить кэширование метамодели программы. Значение по умолчанию: false;
  • <timeout>NUMBER</timeout> - таймаут анализа одного файла (в минутах). Значение по умолчанию: 10;
  • <verbose>BOOLEAN</verbose> - сохранять ли временные файлы анализатора (например json со структурой анализируемого проекта). Значение по умолчанию: false;
  • <javaPath>PATH</javaPath> - путь до java интерпретатора, с которыми будет запускаться ядро анализатора. Значение по умолчанию: java из переменной окружения PATH;
  • <jvmArguments>FLAG, ....</jvmArguments> - дополнительные флаги JVM, с которыми будет запускаться ядро анализатора. Значение по умолчанию: -Xss64m;

Плагин для Gradle

Для проектов со сборочной системой Gradle можно воспользоваться плагином pvsstudio-gradle-plugin. Для этого необходимо добавить следующее в файл build.gradle:

buildscript {
  repositories {
    mavenCentral()
    maven {
      url uri('http://files.viva64.com/java/pvsstudio-maven-repository/')
    }
  }
  dependencies {
    classpath group: 'com.pvsstudio',
              name: 'pvsstudio-gradle-plugin',
              version: '7.09.41421'
  }
}

apply plugin: com.pvsstudio.PvsStudioGradlePlugin
pvsstudio {
  outputType = 'text'
  outputFile = 'path/to/output.txt'
}

После этого можно запустить анализ:

$ ./gradlew pvsAnalyze

Ввод лицензии

Чтобы ввести данные лицензии можно воспользоваться следующей командой:

./gradlew pvsCredentials "-Ppvsstudio.username=USR" "-Ppvsstudio.serial=KEY"

После этого информация о лицензии будет сохранена в %APPDATA%/PVS-Studio-Java/PVS-Studio.lic в ОС Windows или в ~/.config/PVS-Studio-Java/PVS-Studio.lic в macOS и Linux.

Конфигурация

В блоке "pvsstudio" производится настройка анализатора. Ниже представлен список настроек анализатора.

  • outputFile = "PATH" - путь до файла с отчетом анализатора. Значение по умолчанию: $projectDir/PVS-Studio. Примечание: для отчета в формате 'fullhtml' в outputFile необходимо указать директорию, в которой будет создана папка с именем 'fullhtml' с отчетом анализатора. Значение по умолчанию: $projectDir/fullhtml;
  • outputType = "TYPE" - формат отчета анализатора (text, log, json, xml, tasklist, html, fullhtml, errorfile). Значение по умолчанию: json;
  • threadsNum = NUMBER - число потоков анализа. Значение по умолчанию: число доступных процессоров;
  • sourceTreeRoot = "PATH" - общий корневой путь до исходников, который будет использоваться для генерации отчёта анализатора с относительными путями до проверяемых исходных файлов. Значение по умолчанию отсутствует;
  • enabledWarnings = ["V6XXX", ....] - список активных диагностик. При задании включённых диагностик, не указанные здесь будут отключены. Значение по умолчанию отсутствует. При отсутствии значения данного параметра все диагностики считаются включенными (если дополнительно не задан параметр disabledWarnings);
  • disabledWarnings = ["V6XXX", ....] - список выключенных диагностик. При задании отключённых диагностик, не указанные здесь будут считаться включёнными. Значение по умолчанию отсутствует. При отсутствии данного параметра все диагностики считаются включёнными (если дополнительно не задан параметр enabledWarnings);
  • exclude = ["PATH", ....] - список файлов и/или директорий, которые нужно исключить из анализа (абсолютные или относительные пути). Значение по умолчанию отсутствует. При отсутствии данного параметра будут проанализированы все файлы (если дополнительно не задан параметр analyzeOnly);
  • analyzeOnly = ["PATH", ....] - список файлов и/или директорий, которые нужно проанализировать (абсолютные или относительный пути). Значение по умолчанию отсутствует. При отсутствии данного параметра будут проанализированы все файлы (если дополнительно не задан параметр exclude);
  • suppressBase = "PATH" - путь до suppress файла, содержащего подавленные сообщения анализатора, которые не будут выданы в отчёте об анализе. Добавить сообщения в suppress файл можно через интерфейс PVS-Studio IDE плагина для IntelliJ IDEA. Значение по умолчанию: $projectDir/.PVS-Studio/suppress_base.json;
  • failOnWarnings = BOOLEAN - прерывать ли сборку если анализатор выдал какое-либо предупреждение. Значение по умолчанию: false;
  • incremental = BOOLEAN - запускать ли анализ инкрементально (в этом режиме анализируются только изменившиеся файлы). Значение по умолчанию: false;
  • forceRebuild = BOOLEAN - флаг, позволяющий принудительно перестроить целиком закэшированную метамодель программы, содержащую информацию о её структуре и типах данных. Значение по умолчанию: false;
  • disableCache = BOOLEAN - флаг, позволяющий отключить кэширование метамодели программы. Значение по умолчанию: false;
  • timeout = NUMBER - таймаут анализа одного файла (в минутах). Значение по умолчанию: 10;
  • verbose = BOOLEAN - сохранять ли временные файлы анализатора (например json со структурой анализируемого проекта). Значение по умолчанию: false;
  • javaPath = "PATH" - путь до java интерпретатора, с которыми будет запускаться ядро анализатора. Значение по умолчанию: java из переменной окружения PATH;
  • jvmArguments = ["FLAG", ....] - дополнительные флаги JVM, с которыми будет запускаться ядро анализатора. Значение по умолчанию: ["-Xss64m"];

Плагин для IntelliJ IDEA

Анализатор PVS-Studio Java можно также использовать в виде плагина к IntelliJ IDEA. В таком случае разбор структуры проекта производится средствами этой IDE, а плагин предоставляет удобный графический интерфейс для работы с анализатором.

Плагин PVS-Studio для IDEA можно установить из официального репозитория плагинов JetBrains или из репозитория на нашем сайте. Ещё один способ установки (включая ядро анализатора) - через установщик PVS-Studio для Windows, доступный на странице загрузки.

Ниже приведен порядок установки плагина из нашего репозитория.

1) File -> Settings -> Plugins

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image1.png

2) Manage Plugin Repositories

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image3.png

3) Add repository (http://files.viva64.com/java/pvsstudio-idea-plugins/updatePlugins.xml)

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image4.png

4) Install

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image5.png

После этого нужно ввести данные лицензии.

1) Analyze -> PVS-Studio -> Settings

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image7.png

2) Вкладка Registration:

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image9.png

Теперь можно запустить анализ текущего проекта:

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image11.png

Интеграция PVS-Studio с Continuous Integration системами и SonarQube

Любой из перечисленных способов интеграции анализатора в сборочную систему можно использовать для автоматизированного анализа в Continuous Integration системах. Это можно сделать в Jenkins, TeamCity и других, настроив автоматический запуск анализа и уведомление о найденных ошибках.

Также возможна интеграция с платформой непрерывного контроля качества SonarQube с помощью плагина PVS-Studio. Инструкция по настройке доступна на странице: "Интеграция результатов анализа PVS-Studio в SonarQube".

Использование ядра анализатора напрямую

В случае, если ни один из приведенных выше способов интеграции в проект не подходит, можно использовать ядро анализатора напрямую. Ядро анализатора можно установить через установщик PVS-Studio для Windows (доступный на странице загрузки) или скачать по ссылке: http://files.viva64.com/java/pvsstudio-cores/7.09.41421.zip

Анализатору для работы необходим набор исходных файлов (или директорий с исходными файлами) для анализа, а так же classpath.

Набор исходных файлов для анализа указывается с помощью флага -s, а classpath с помощью флага -e. Кроме того, с помощью флага --ext-file можно указать файл, в котором перечислены все вхождения в classpath, разделенные при помощи pathSeparator (разделитель ':' в Unix системах и ';' в Windows).

Все доступные флаги ядра можно просмотреть с помощью следующей команды:

java -jar pvs-studio.jar --help

Примеры быстрого запуска:

java -jar pvs-studio.jar -s A.java B.java C.java -e Lib1.jar Lib2.jar -j4 -o report.txt -O text

java -jar pvs-studio.jar -s src/main/java --ext-file classpath.txt -j4 -o report.txt -O text

Подавление сообщений анализатора

Имеется несколько способов подавления сообщений анализатора.

1. При помощи специальных комментариев:

void f() {
    int x = 01000; //-V6061
}

2. При помощи suppress файла

Создать suppress файл можно через интерфейс PVS-Studio IDE плагина для IntelliJ IDEA. Путь до suppress файла можно указать в качестве параметра maven или gradle плагина, а так же в качестве параметра при прямом запуске ядра анализатора.

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image13.png

При подавлении сообщения через IDEA, suppress файл будет создан в директории .PVS-Studio, расположенной в директории открытого в IDE проекта, с именем suppress_base.json;

3. При помощи аннотаций @SuppressWarnings(....)

Анализатор знает о некоторых аннотациях и может не выдавать предупреждения на код, который уже был размечен. Например:

@SuppressWarnings("OctalInteger")
void f() {
    int x = 01000;
}

Описание распространённых проблем и их решение

Возникает "GC overhead limit exceeded" или завершение анализа по таймауту

Проблему нехватки памяти можно решить увеличением доступного объема памяти и стека.

В плагине для Maven:

<jvmArguments>-Xmx4096m, -Xss256m</jvmArguments>

В плагине для Gradle:

jvmArguments = ["-Xmx4096m", "-Xss256m"]

В плагине для IntelliJ IDEA:

1) Analyze -> PVS-Studio -> Settings

2) Вкладка Environment -> JVM arguments

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image14.png

Обычно объема памяти по умолчанию может не хватать при анализе сгенерированного кода с большим количеством вложенных конструкций.

Возможно стоит исключить этот код из анализа (с помощью exclude), чтобы не тратить на него лишнее время.

Как изменить версию Java для запуска анализатора?

По умолчанию анализатор запускает ядро с java из переменной окружения PATH. Если необходимо запустить анализ с какой-то другой версией, ее можно указать вручную.

В плагине для Maven:

<javaPath>C:/Program Files/Java/jdk1.8.0_162/bin/java.exe</javaPath>

В плагине для Gradle:

javaPath = "C:/Program Files/Java/jdk1.8.0_162/bin/java.exe"

В плагине для IntelliJ IDEA:

1) Analyze -> PVS-Studio -> Settings

2) Вкладка Environment -> Java executable

https://import.viva64.com/docx/manual/PVS-Studio_Java_ru/image14.png

Не удается запустить анализ (возникают ошибки V00X)

В случае если не удается запустить анализ, пожалуйста, напишите нам в поддержку (support@viva64.com) и приложите текстовые файлы из директории .PVS-Studio (находится в директории с проектом).

PVS-Studio для Embedded-разработки

Разработка для встраиваемых систем имеет свою специфику и подходы, но контроль качества кода в этой сфере не менее важен, чем в других. PVS-Studio поддерживает анализ проектов, которые используют следующие компиляторы:

Поддерживаемыми платформами для разработки являются Windows, Linux и macOS.

Анализ проектов в Linux и macOS

После установки анализатора в Linux или macOS станет доступна утилита для анализа проектов - pvs-studio-analyzer.

В утилиту добавлено автоматическое определение поддерживаемых компиляторов, но если используется модифицированный или расширенный пакет разработки, то с помощью параметра --compiler можно перечислить имена используемых embedded-компиляторов:

-C [COMPILER_NAME...], --compiler [COMPILER_NAME...]
    Filter compiler commands by compiler name

Анализ проектов в Windows

После установки анализатора в Windows будет доступен большой набор различных утилит, предназначенных для разных режимов работы анализатора.

Консольный режим

Анализ проекта можно автоматизировать с помощью последовательного запуска следующих команд утилиты CLMonitor:

"C:\Program Files (x86)\PVS-Studio\CLMonitor.exe" monitor
<build command for your project>
"C:\Program Files (x86)\PVS-Studio\CLMonitor.exe" analyze ... -l report.plog ...

Примечание. Команда monitor запускает процесс в неблокирующем режиме.

Графический режим

В утилите Сompiler Monitoring UI необходимо перейти в режим мониторинга сборки в меню Tools > Analyze Your Files (C/C++) или щёлкнув по значку "око" на панели инструментов:

https://import.viva64.com/docx/manual/EmbeddedDevelopment_ru/image1.png

Перед запуском мониторинга сборки будет доступно следующее меню для дополнительной настройки анализа:

https://import.viva64.com/docx/manual/EmbeddedDevelopment_ru/image2.png

После запуска мониторинга следует выполнить сборку проекта в IDE или с помощью сборочных скриптов, после чего в следующем окне нажать Stop Monitoring:

https://import.viva64.com/docx/manual/EmbeddedDevelopment_ru/image3.png

Результаты анализа будут доступны в утилите Сompiler Monitoring UI после анализа файлов, участвующих в компиляции.

Предупреждения с номером V001

В отчёте анализатора могут встречаться подобные предупреждения:

V001: A code fragment from 'source.cpp' cannot be analyzed.

Разработчики компиляторов для встраиваемых систем часто отходят от стандартов и добавляют в компилятор нестандартные расширения. В сфере микроконтроллеров это особенно распространено и не является чем-то необычном для разработчиков.

Но для анализатора кода это нестандартный C или C++ код, который требует дополнительной поддержки. Если на вашем коде возникают такие предупреждения, пришлите нам архив с препроцессированными *.i файлами, полученными из проблемных исходников, и мы добавим поддержку новых расширений компилятора.

Включить режим сохранения таких файлов во время анализа можно следующими способами:

  • В утилите Сompiler Monitoring UI в меню Tools > Options... > Common Analyzer Settings > RemoveIntermediateFiles выставить значение false;
  • Утилите pvs-studio-analyzer передать параметр --verbose.

Используемый компилятор отсутствует в списке

Рынок пакетов разработки для встраиваемых систем очень обширен, поэтому если вы не нашли свой компилятор в списке поддерживаемых, сообщите нам через форму обратной связи о своём желании попробовать PVS-Studio, подробно описав используемые инструменты разработки.

Static Application Security Testing (SAST)

Для повышения качества кода или безопасности устройств в сфере разработки для встраиваемых систем часто следуют различным стандартам кодирования, например, SEI CERT Coding Standard и MISRA, а также стараются избегать появления потенциальных уязвимостей, руководствуюсь списком Common Weakness Enumeration (CWE). Проверка соответствия кода таким критериям присутствует в PVS-Studio.

Анализ проекта в среде PlatformIO

Для проверки embedded проектов с помощью PVS-Studio можно использовать мультиплатформенная среду разработки PlatformIO. Она берет на себя работу по поддержке инструментов сборки и отладки, а также по управлению библиотеками. Запускается под основными операционными системами, такими как Windows, macOS и Linux.

Для включения анализа с помощью PVS-Studio нужно добавить в конфигурационный файл проекта (platformio.ini):

check_tool = pvs-studio
check_flags = pvs-studio: --analysis-mode=4

После чего вызвать в терминале команду:

pio check

Более подробно о поддержке статического анализа в PlatformIO можно узнать на сайте проекта, а так же на странице, посвященной конфигурации PVS-Studio.

Дополнительные ссылки

В этом документе собраны особенности запуска анализатора и проверки проектов для встраиваемых систем. В остальном запуск анализатора и его настройка производятся так же, как и для других типов проектов. Перед началом использования анализатора рекомендуется ознакомиться со следующими страницами документации:

Знакомство со статическим анализатором кода PVS-Studio на Windows

PVS-Studio - статический анализатор С, С++, C# и Java кода, предназначенный для облегчения задачи поиска и исправления различного рода ошибок. Анализатор можно использовать в Windows, Linux и macOS.

При работе с Windows анализатор интегрируется в Visual Studio в качестве плагина, предоставляя программисту удобный интерфейс для ориентации в коде и поиска проблемных мест. Также присутствует приложение C and C++ Compiler Monitoring UI (Standalone.exe), независимое от Visual Studio и позволяющее проверять файлы, компилируемые не только с помощью Visual C++, но и с использованием GCC (MinGW), Clang. Консольная утилита PVS-Studio_Cmd.exe позволит выполнять проверку MSBuild / Visual Studio проектов без запуска IDE или Compiler Monitoring UI, что позволит, например, использовать анализатор как часть процесса CI.

PVS-Studio для Linux представляет собой консольное приложение.

В данном документе описываются основы работы с PVS-Studio на операционных системах семейства Windows. Для получения информации о работе в среде Linux обратитесь к разделам документации "Установка и обновление PVS-Studio в Linux" и "Как запустить PVS-Studio в Linux и macOS".

Преимущества использования статического анализатора

Статический анализатор не заменяет другие инструменты поиска ошибок - он дополняет их. Внедрение такого инструмента позволяет устранять многие ошибки на этапе "зарождения", тем самым экономя время и ресурсы на их последующее устранение. Ведь чем раньше найдена ошибка, тем дешевле стоимость её исправления. Из этого следует ещё один вывод - статический анализатор необходимо использовать регулярно, именно в таком случае он проявит себя наиболее эффективно.

Краткий обзор возможностей

Уровни предупреждений и наборы диагностических правил

PVS-Studio разделяет все предупреждения по 3 уровням достоверности: High, Medium и Low. Также некоторые сообщения относятся к особой категории Fails. Рассмотрим эти уровни подробнее:

  • High (1) - включает в себя предупреждения с максимальным уровнем достоверности. Такие предупреждения часто указывают на ошибки, требующие немедленного исправления.
  • Medium (2) - содержит менее достоверные предупреждения, на которые все же стоит обратить пристальное внимание.
  • Low (3) - предупреждения с минимальным уровнем достоверности, указывающие на несущественные неточности в коде. Среди таких предупреждений обычно велик процент ложных срабатываний.
  • Fails - внутренние сообщения анализатора, информирующие о возникновении каких-то проблем при работе. В группу Fails попадают сообщения об ошибках анализатора (например, сообщения с кодами V001, V003 и т.п.), а также любой необработанный вывод вспомогательных программ, используемых самим анализатором во время анализа (препроцессор, командный процессор cmd), выдаваемый ими в stdout/stderr. Например, в группу Fails может попасть сообщение препроцессора об ошибках препроцессирования, доступа к файлам (файл не существует или заблокирован антивирусом) и т.п.

Стоит помнить, что конкретный код ошибки не обязательно привязывает её к определённому уровню достоверности, а распределение сообщений по уровням сильно зависит от контекста, в котором они были сгенерированы. При использовании плагина для Microsoft Visual Studio или в приложении C and C++ Compiler Monitoring UI окно вывода диагностических сообщений содержит кнопки уровней, позволяющие сортировать сообщения по мере необходимости.

Анализатор содержит 5 видов диагностических правил:

  • General (GA) - диагностики общего плана. Основной набор диагностических правил PVS-Studio.
  • Optimization (OP) - диагностики микрооптимизации. Указания по повышению эффективности и безопасности кода.
  • 64-bit (64) - диагностики, позволяющие выявлять специфические ошибки, связанные с разработкой 64-битных приложений, а также переносом кода с 32-битной на 64-битную платформу.
  • Customers' Specific (CS) - узкоспециализированные диагностики, разработанные по просьбам пользователей. По умолчанию этот набор диагностик отключен.
  • MISRA - диагностики, разработанные в соответствии со стандартом MISRA (Motor Industry Software Reliability Association). По умолчанию этот набор диагностик отключен.

Краткие обозначения групп диагностик (GA, OP, 64, CS, MISRA), наряду с номерами уровней достоверности предупреждений (1, 2, 3), используются для сокращенной формы записи, например, в параметрах командной строки. Пример: GA:1,2.

Выбор группы диагностических правил отображает или скрывает соответствующие сообщения.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image1.png

С подробным списком диагностических правил вы можете ознакомиться в соответствующем разделе документации.

Сообщения анализатора можно группировать и фильтровать по различным критериям. Для получения более подробной информации о работе со списком предупреждений анализатора обратитесь к разделу документации "Работа со списком диагностических сообщений".

PVS-Studio и Microsoft Visual Studio

При установке PVS-Studio присутствует возможность выбора того, в какие среды Microsoft Visual Studio необходимо провести интеграцию.

После выбора необходимых пунктов и установки, PVS-Studio интегрируется IDE. На скриншоте ниже можно увидеть соответствующий пункт в меню Visual Studio, а также окно вывода диагностических сообщений.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image3.png

В меню настроек есть возможность настроить PVS-Studio оптимальным образом для удобства работы. Например, присутствуют следующие возможности:

  • Выбор препроцессора;
  • Исключение файлов и папок из проверки;
  • Выбор типов диагностических сообщений, выводящихся при проверке;
  • Множество прочих настроек.

Скорее всего, для первого знакомства все эти настройки вам не понадобятся, но в будущем они позволят оптимизировать работу с PVS-Studio.

PVS-Studio и IntelliJ IDEA

При установке анализатора присутствует возможность интеграции плагина PVS-Studio в IDE IntelliJ IDEA, что позволит проводить анализ и работать с отчётами анализатора непосредственно из IDE.

После установки плагин будет доступен в меню 'Analyze' ('Analyze' > 'PVS-Studio'). Ниже представлен скриншот IntelliJ IDEA с интегрированным плагином PVS-Studio.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image5.png

В меню настроек, как и в случае с плагином для Visual Studio, также присутствуют возможности отключения диагностических правил, исключение файлов / директорий из анализа и пр.

Особенности работы Java анализатора, а также альтернативные способы установки (включая установку плагинов для Maven, Gradle) описаны в разделе документации "Как запустить PVS-Studio Java".

PVS-Studio и JetBrains Rider

При установке анализатора присутствует возможность интеграции плагина PVS-Studio в IDE JetBrains Rider, что позволит проводить анализ и работать с отчётами анализатора непосредственно из IDE.

После установки плагин доступен в меню 'Tools'. Анализ текущего solution / проекта можно выполнить следующим образом: 'Tools' > 'PVS-Studio' > 'Check Current Solution/Project'.

Ниже представлен скриншот IDE JetBrains Rider с интегрированным плагином PVS-Studio.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image7.png

Более подробно использование плагина PVS-Studio для IDE JetBrains Rider описано в разделе документации "Работа PVS-Studio в JetBrains Rider".

C and C++ Compiler Monitoring UI (Standalone.exe)

PVS-Studio может использоваться независимо от интегрированной среды разработки Microsoft Visual Studio. Compiler Monitoring UI позволяет проверять проекты в процессе их сборки. В этой версии также поддерживаются переходы по коду по диагностическим сообщениям, поиск фрагментов кода, определений макросов и типов данных. Более подробно работа с этим приложением описана в разделе документации "Просмотр результатов анализа в приложении C and C++ Compiler Monitoring UI".

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image9.png

PVS-Studio_Cmd.exe

PVS-Studio_Cmd.exe - модуль, позволяющий выполнять анализ решений Visual Studio (.sln), а также Visual C++ и Visual C# проектов (.vcxproj, .csproj) из командной строки. Это может быть полезно, например, в случае необходимости интеграции статического анализа на сборочном сервере. PVS-Studio_Cmd.exe позволяет проводить как полный анализ целевого проекта, так и инкрементальный (анализ файлов, изменившихся с момента последний сборки). Представление кода возврата работы утилиты в виде битовой маски позволяет получить подробную информацию о результатах анализа и идентифицировать проблемы, в случае их наличия. Таким образом, используя модуль PVS-Studio_Cmd.exe, можно достаточно 'тонко' настроить сценарий статического анализа кода и внедрить его в процесс CI. Более подробно использование модуля PVS-Studio_Cmd.exe описано в разделе документации "Проверка Visual C++ (.vcxproj) и Visual C# (.csproj) проектов из командной строки с помощью PVS-Studio".

Справочная система и техническая поддержка

PVS-Studio обладает обширной справочной системой диагностических сообщений. Эта база доступна как при работе с инструментом PVS-Studio, так и на официальном сайте. К различным диагностическим сообщениям прилагаются примеры кода, содержащего подобные ошибки, описание проблемы, а также возможные варианты исправления.

Чтобы изучить описание той или иной диагностики, достаточно кликнуть левой кнопкой мыши по номеру диагностики в окне вывода сообщений. Эти номера оформлены как гиперссылки.

Поддержка для PVS-Studio осуществляется посредством электронной почты. Так как с клиентами общаются непосредственно разработчики анализатора, это позволяет быстро получать ответы на самые разные вопросы.

Системные требования и установка PVS-Studio

Анализатор PVS-Studio интегрируется в среды разработки Microsoft Visual Studio 2019, 2017, 2015, 2013, 2012, 2010. Системные требования к анализатору можно найти в соответствующем разделе документации.

Получив установочный пакет PVS-Studio, можно приступить к установке программы.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image11.png

После подтверждения лицензионного соглашения будет предоставлен выбор вариантов интеграции PVS-Studio в поддерживаемые среды разработки: Microsoft Visual Studio. Варианты интеграции, недоступные на текущей системе, будут затемнены. В случае, если на машине установлено несколько версий одной или разных IDE, возможна интеграция анализатора во все имеющиеся версии.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image12.png

Для того чтобы удостовериться, что инструмент PVS-Studio корректно установлен, можно запустить IDE и открыть окно About (пункт меню Help). При этом анализатор PVS-Studio должен присутствовать в списке установленных компонентов.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image13.png

Основы работы с PVS-Studio

При работе в IDE Visual Studio можно запускать различные варианты анализа - на решение, проект, файл, выбранные элементы и т.п. Например, запуск анализа решения выполняется следующим образом: "PVS-Studio -> Check -> Solution".

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image14.png

После запуска проверки на экране появится индикатор прогресса с кнопками Pause (приостановить анализ) и Stop (прервать анализ). Обнаруженные потенциально опасные конструкции во время анализа будут выводиться в окно найденных дефектов.

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image15.png

Термин "потенциально опасная конструкция" означает, что данную конкретную строку кода анализатор посчитал дефектом. Является ли эта строка реальным дефектом в приложении или нет - определить может только программист, основываясь на своем знании приложения. Этот принцип работы с анализаторами кода очень важно правильно понимать. Никакой инструмент не может полностью заменить программиста в работе по исправлению ошибок в программах. Только программист, основываясь на своих знаниях, может это сделать. Но инструмент может и должен помочь программисту в этом. Поэтому задача анализатора кода - это сократить количество мест в программе, которое должен просмотреть и разобрать программист.

Работа со списком диагностических сообщений

Скорее всего, в больших реальных проектах диагностических сообщений будет не несколько десятков, а несколько сотен или даже тысяч. И просмотр всех подобных сообщений может быть непростой задачей. Для того чтобы облегчить ее, в анализаторе PVS-Studio имеются несколько механизмов, таких как фильтрация сообщений по коду ошибки, фильтрация по содержимому текста диагностического сообщения, фильтрация на основе путей к файлам и другие. Рассмотрим примеры использования систем фильтрации.

Предположим, что вы уверены, что диагностические сообщения с кодом V112 (использование магических чисел) никогда не являются реальными ошибками в вашем приложении. Тогда можно отключить показ этих диагностических сообщений с помощью настроек анализатора кода на вкладке "Detectable Errors (C++)".

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image16.png

После отключения предупреждения с определённым кодом соответствующие предупреждения будут отфильтрованы в окне вывода, перезапускать анализ не требуется. Если же включить обратно показ таких сообщений, то они вновь появятся в списке предупреждений.

Теперь рассмотрим другой вариант фильтрации на основе текста диагностических сообщений. Рассмотрим пример предупреждения анализатора и кода, на который оно было выдано:

obj.specialFunc(obj);

Предупреждение анализатора: V678 An object is used as an argument to its own method. Consider checking the first actual argument of the 'specialFunc' function.

Анализатор счёл подозрительным, что в качестве аргумента методу передаётся тот же объект, у которого этот метод и вызывается. Программисту, в отличии от анализатора, может быть известно о том, что такое использование данного метода вполне допустимо. Поэтому может возникнуть необходимость отфильтровать все подобные предупреждения. Сделать это можно, добавив соответствующий фильтр в настройках "Keyword Message Filtering".

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image18.png

После этого все диагностические сообщения, текст которых содержит указанное выражение, пропадут из списка без необходимости перезапускать анализатора кода. Вернуть их можно просто удалив выражение из фильтра.

Ещё одним механизмом сокращения количества диагностических сообщений является фильтрация по маскам имён файлов проекта и путям к ним.

Предположим, в вашем проекте используется библиотека Boost. Анализатор будет, конечно же, сообщать и о потенциальных проблемах в этой библиотеке. Скорее всего, вас эти предупреждения интересовать не будут, поэтому целесообразно отфильтровать их. Сделать это можно, просто добавив путь к папке с Boost на странице "Don't check files":

https://import.viva64.com/docx/manual/PVS-Studio_overview_ru/image20.png

После этого диагностические сообщения, относящиеся к файлам в этой папке, не будут показаны.

Также в PVS-Studio имеется функция "Mark as False Alarm". Благодаря ей возможно пометить в исходном коде те строки, на которые анализатор выдал предупреждения, являющиеся ложными. После разметки анализатор более не будет выдавать диагностических сообщений на этот код.

Так в этом примере отключен вывод диагностического сообщения с кодом V640:

for (int i = 0; i < m; ++i)
  for (int j = 0; j < n; ++j)
    matrix[i][j] = Square(i) + 2*Square(j);
  cout << "Matrix initialization." << endl; //-V640
....

Подробно этот механизм описана в разделе "Подавление ложных предупреждений".

Есть также ряд других способов повлиять на выводимые диагностические сообщения путем настроек анализатора кода, но в рамках данного документа они не рассматриваются. Рекомендуем обратиться к документации по настройкам анализатора кода.

Надо ли добиваться исправления всех потенциальных ошибок, на которые указывает анализатор?

Когда вы просмотрите все сообщения, которые выдал анализатор кода, то вы найдете как реальные ошибки в программах, так и конструкции, не являющиеся ошибочными. Дело в том, что анализатор не может на 100% точно определить все ошибки в программах без так называемых "ложных срабатываний". Только программист, зная и понимая программу, может определить есть в конкретном месте ошибка или нет. Анализатор кода же только существенно сокращает количество мест, которые необходимо просмотреть разработчику.

Таким образом, добиваться исправления всех потенциальных проблем, на которые указывает анализатор кода, смысла, конечно же, нет.

Механизмы подавления отдельных предупреждений и массового подавления сообщений анализатора описаны в разделах документации "Подавление ложных предупреждений" и "Массовое подавление сообщений анализатора" соответственно.

Проверка проектов Visual Studio / MSBuild / .NET Core из командной строки с помощью PVS-Studio

В данном документе описывается использование command line утилит для анализа MSBuild проектов (.vcxproj / .csproj) и решений Visual Studio (solutions).

В данном документе описывается использование command-line утилит. Использование плагинов для IDE Visual Studio и Rider описано в соответствующих разделах документации: "Знакомство со статическим анализатором кода PVS-Studio на Windows", "Работа PVS-Studio в JetBrains Rider".

Command line анализатор MSBuild / .NET Core проектов имеет разные имена на разных поддерживаемых анализатором платформах:

  • PVS-Studio_Cmd (анализ решений, C#, C++ проектов на Windows);
  • pvs-studio-dotnet (анализ решений, C# проектов на Linux / macOS);

Описываемые ниже особенности актуальны для обеих утилит. Примеры с PVS-Studio_Cmd / pvs-studio-dotnet являются взаимозаменяемыми, если явно не указано обратное.

Примечание. Для анализа C++ проектов, не использующих сборочную систему MSBuild, на Windows следует воспользоваться системой мониторинга компиляции или прямой интеграцией анализатора в сборочную систему. Анализ C++ проектов на Linux / macOS подробно описан в этом разделе документации.

Запуск анализа sln и csproj/vcxproj файлов

Command line утилиты по умолчанию распаковываются в следующие директории:

  • PVS-Studio_Cmd.exe
    • Windows: "C:\Program Files (x86)\PVS-Studio\";
  • pvs-studio-dotnet
    • Linux: "/usr/share/pvs-studio-dotnet/";
    • macOS: "/usr/local/share/pvs-studio-dotnet".

Команда '--help' выведет все доступные аргументы анализатора:

PVS-Studio_Cmd.exe --help

Рассмотрим основные аргументы анализатора:

  • --target (-t): обязательный параметр. Позволяет указать объект для проверки (sln или csproj/vcxproj файл);
  • --output (-o): путь до файла, в который будут записаны результаты анализа. Если данный параметр пропущен, файл отчёта анализатора будет создан рядом с файлом, указанным через флаг '--target'. Поддерживается сохранение отчёта анализатора в 2 форматах: .json и .plog. Тип формата определяется по указанному расширению. По умолчанию, без указания данного флага, будет создан отчёт в формате .plog;
  • --platform (-p) и --configuration (-c): платформа и конфигурация, для которых будет запущена проверка. Если данные параметры не указаны, будет выбрана первая из доступных пар "платформа|конфигурация" (при проверке sln файла) либо "Debug|AnyCPU" (при проверке отдельного csproj проекта) или "Debug|Win32" (при проверке отдельного vcxproj проекта);
  • --sourceFiles (-f): путь до текстового файла, содержащего список путей до исходных файлов для анализа (каждый должен быть на отдельной строке). Поддерживаются относительные и абсолютные пути. В данном режиме при анализе C и C++ файлов генерируется кэш зависимостей компиляции, расположением которого можно управлять с помощью флага '-D';
  • --dependencyRoot (-D): опциональный путь к директории для размещения кэшей зависимости исходных файлов. Работает в дополнение к флагу '--sourceFiles' (-f);
  • --dependencyCacheSourcesRoot (-R): опциональный путь, который используется для создания относительных путей в кэшах зависимостей исходных файлов, генерируемом при использовании флага '--sourceFiles' (-f);
  • --settings (-s): путь до файла настроек PVS-Studio. Если параметр опущен, будет использован файл настроек Settings.xml, находящийся в директории "C:\Users\%UserName%\AppData\Roaming\PVS-Studio\" на Windows или "~/.config/PVS-Studio/" на Linux / macOS. Эти же файлы настроек используются плагинами (Visual Studio, Rider), что даёт возможность их редактирования с помощью интерфейса PVS-Studio плагина в данных IDE. Обратите внимание, что для работы анализатора под Windows файл настроек должен содержать регистрационную информацию. Различные способы ввода лицензии описаны здесь. В зависимости от используемого файла настроек, применяются следующие правила:
    • при использовании файла настроек по умолчанию он должен содержать регистрационную информацию;
    • при явном указании пути до файла настроек регистрационная информация должна быть записана или в указанном файле настроек, или в файле настроек, используемом по умолчанию;
  • --progress (-r): включение режима подробного логгирования в stdout прогресса проверки (по умолчанию выключено);
  • --suppressAll (-a): добавить неподавленные сообщения в suppress файлы соответствующих проектов (по умолчанию выключено). При наличии данного флага все сообщения будут добавлены в базу подавленных сообщений после сохранения результата проверки. Флаг поддерживает 2 режима работы.
    • SuppressOnly добавляет сообщения из переданного отчёта о работе анализатора в suppress файлы без запуска анализа;
    • AnalyzeAndSuppress запускает анализ, сохраняет отчёт о работе анализатора, и только затем подавляет найденные в нём сообщения. Этот режим позволит вам при регулярных запусках получать отчёт анализатора, в котором содержатся только новые сообщения на изменённый \ написанный код, т.е. новые сообщения попадают в новый лог и сразу же подавляются - при последующей проверке их уже не будет выдано. Тем не менее, если вам всё же потребуется посмотреть старые сообщения (без перепроверки), рядом с отчётом о работе анализатора, содержащим новые сообщения, будет сохранён файл с полным отчётом о проверке (только для .plog отчётов анализатора). Подробнее про режим подавления сообщений можно прочитать в этом разделе документации;
  • --sourceTreeRoot (-e): корневая часть пути, которую PVS-Studio будет использовать при генерации относительных путей в диагностических сообщениях. Задание этого параметра переопределяет значение 'SourceTreeRoot' в настройках PVS-Studio;
  • -- incremental (-i): режим инкрементального анализа. Для получения подробной информации об инкрементальном анализе в PVS-Studio обратитесь к разделу "Режим инкрементального анализа PVS-Studio". Доступны следующие режимы работы инкрементального анализа:
    • Scan – проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ. Непосредственно анализ выполнен не будет. Будут учтены изменения, произведенные с момента последней сборки, предыдущая история изменений будет удалена.
    • AppendScan – проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ. Непосредственно анализ выполнен не будет. Будут учтены изменения, произведенные с момента последней сборки, а также все предыдущие изменения.
    • Analyze – выполнить инкрементальный анализ. Этот шаг должен выполняться после выполнения шагов Scan или AppendScan, и может выполняться как до, так и после сборки решения или проекта. Статический анализ будет выполнен только для файлов из списка, полученного в результате выполнения команд Scan или AppendScan.
    • ScanAndAnalyze - проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ, и сразу же выполнить инкрементальный анализ измененных файлов с исходным кодом. Будут учтены изменения, произведенные с момента последней сборки.
  • --msBuildProperties (-m): позволяет задать или переопределить свойства уровня проекта. Для задания или переопределения нескольких свойств уровня проекта, используйте символ "|", например: --msBuildProperties WarningLevel=2|OutDir=bin\OUT32\
  • --excludeDefines (-x): список символов, которые будут исключены из текущего набора при анализе проекта. При необходимости перечисления нескольких символов в качестве разделителя используется ';'. Пример: --excludeDefines "DEF1;DEF2". Данная опция учитывается только при анализе C# проектов.
  • --appendDefines (-d): список символов, которые будут добавлены к текущему набору при анализе проекта. При необходимости перечисления нескольких символов в качестве разделителя используется ';'. Пример: --appendDefines "DEF1;DEF2". Данная опция учитывается только при анализе C# проектов.
  • --selectProjects (-S): список проектов анализируемого решения (sln), которые будут проанализированы. Остальные проекты будут исключены из анализа. Поддерживается перечисление проектов через имя проектного файла (c расширением или с без него), по абсолютному или относительному пути. При необходимости перечисления нескольких проектов в качестве разделителя используется ';'. Пример: --selectProjects Project1;"Project 2.vcxproj";".\Project3\Project3.csproj".
  • --excludeProjects (-E): список проектов анализируемого решения (sln), которые будут исключены из анализа. Поддерживается перечисление проектов через имя проектного файла (c расширением или с без него), по абсолютному или относительному пути. При необходимости перечисления нескольких проектов в качестве разделителя используется ';'. Пример: --excludeProjects Project1;"Project 2.vcxproj";".\Project3\Project3.csproj".
  • --rulesConfig (-C): путь к файлу конфигурации диагностик .pvsconfig. Может быть использован совместно с файлами конфигурации из проектов / решения и файлами конфигурации из каталогов:
    • Windows: "%AppData%\PVS-Studio\";
    • Linux / macOS: "~/.config/PVS-Studio/".

Приведём пример запуска проверки списка файлов, записанных в "pvs.txt", из состава решения "My Solution":

PVS-Studio_Cmd.exe --target "mysolution.sln" --platform "Any CPU" 
--configuration "Release" --output "mylog.plog"
--sourceFiles "pvs.txt" --progress

Command line версия анализатора PVS-Studio поддерживает все настройки по фильтрации\отключению сообщений, доступные в плагинах для Visual Studio и Rider. Вы можете как задать их вручную в xml файле, переданном с помощью аргумента '--settings', так и использовать настройки, заданные через UI плагина, не передавая данного аргумента. Обратите внимание, что IDE плагин PVS-Studio использует отдельный набор настроек для каждого пользователя в системе.

Актуально только для PVS-Studio_Cmd. Если вы установили несколько экземпляров PVS-Studio различных версий для текущего пользователя системы, то все экземпляры программы будут использовать установочную директорию, указанную при последней установке. Во избежание конфликтов в работе анализатора в настройках, передаваемых с аргументом --settings (-s), необходимо указать путь до установочной директории (значение элемента <InstallDir>).

Задание отдельных файлов для проверки

PVS-Studio_Cmd позволяет провести выборочную проверку отдельных файлов, заданных в списке, передаваемом с помощью флага '--sourceFiles' (-f). Список файлов представляет собой простой текстовый файл, в котором построчно указаны пути к проверяемым файлам. Относительные пути к файлам будут раскрыты относительно текущей рабочей директории. Можно указывать как исходные компилируемые файлы (c/cpp для C++ и cs для C#), так и заголовочные файлы (h/hpp для C++).

В данном режиме работы при анализе C и C++ файлов генерируется кэш зависимостей компиляции, который будет использован при последующих запусках анализа. По умолчанию кэши зависимостей сохраняются в специальной поддиректории '.PVS-Studio', рядом с проектными файлами (.vcxproj). При необходимости можно изменить место их хранения при помощи флага '--dependencyRoot' (-D).

Фильтрация списка анализируемых файлов по маске

Для того, чтобы определить набор анализируемых файлов, пути и названия которых соответствуют определенному шаблону, флагу '--sourceFiles' (-f) должен быть передан специально сформированный XML файл. В нем могут содержаться списки абсолютных и относительных путей и\или масок до проверяемых файлов.

<SourceFilesFilters>
  <SourceFiles>
    <Path>C:\Projects\Project1\source1.cpp</Path>
    <Path>\Project2\*</Path>
    <Path>source_*.cpp</Path>
  </SourceFiles>
  <SourcesRoot>C:\Projects\</SourcesRoot>
</SourceFilesFilters>

Коды возврата command-line утилит

Утилиты PVS-Studio_Cmd / pvs-studio-dotnet имеют несколько ненулевых кодов возврата, которые не означают проблемы в работе самой утилиты, т.е. даже если утилита вернула не '0', это ещё не означает, что она "упала". Код возврата представляет собой битовую маску, маскирующую все возможные состояния, возникшие во время работы утилиты. Например, утилита вернёт ненулевой код возврата в случае, если анализатор нашёл в проверяемом коде потенциальные ошибки. Это позволяет обрабатывать такую ситуацию отдельно, например, на сборочном сервере, когда политика использования анализатора не подразумевает наличия срабатываний в коде, заложенном в систему контроля версий.

Коды возврата PVS-Studio_Cmd (Windows)

Рассмотрим далее все возможные коды состояния утилиты, из которых формируется битовая маска кода возврата.

  • '0' - анализ успешно завершён, ошибок в проверяемом коде не найдено;
  • '1' - ошибка (падение) анализатора при проверке одного из файлов;
  • '2' - общая (неспецифичная) ошибка при работе анализатора, перехваченное исключение при работе. Обычно это сигнализирует о наличии ошибки в коде самого анализатора и сопровождается выведением stack trace'а этой ошибки в stderr. Если вам встретилась подобная ошибка, пожалуйста, помогите нам улучшить анализатор и пришлите этот stack trace нам;
  • '4' - какие-то из переданных аргументов командной строки некорректны;
  • '8' - не найден заданный проект, solution или файл настроек анализатора;
  • '16' - заданная конфигурация и (или) платформа не найдены в файле решения;
  • '32' - файл решения или проекта не поддерживается или содержит ошибки;
  • '64' - некорректное расширение проверяемого решения или проекта;
  • '128' - некорректная или просроченная лицензия на анализатор;
  • '256' - в проверяемом коде найдены потенциальные ошибки;
  • '512' - произошла ошибка при выполнении подавления сообщений
  • '1024' - показывает, что лицензия на анализатор истечёт в течение месяца;

Приведём пример скрипта Windows batch для расшифровки кода возврата утилиты PVS-Studio_Cmd:

@echo off

"C:\Program Files (x86)\PVS-Studio\PVS-Studio_Cmd.exe"
-t "YourSolution.sln" -o "YourSolution.plog"

set /A FilesFail = "(%errorlevel% & 1) / 1"
set /A GeneralExeption = "(%errorlevel% & 2) / 2"
set /A IncorrectArguments = "(%errorlevel% & 4) / 4"
set /A FileNotFound = "(%errorlevel% & 8) / 8"
set /A IncorrectCfg = "(%errorlevel% & 16) / 16"
set /A InvalidSolution = "(%errorlevel% & 32) / 32"
set /A IncorrectExtension = "(%errorlevel% & 64) / 64"
set /A IncorrectLicense = "(%errorlevel% & 128) / 128"
set /A AnalysisDiff = "(%errorlevel% & 256) / 256"
set /A SuppressFail = "(%errorlevel% & 512) / 512"
set /A LicenseRenewal = "(%errorlevel% & 1024) / 1024"

if %FilesFail% == 1 echo FilesFail
if %GeneralExeption% == 1 echo GeneralExeption
if %IncorrectArguments% == 1 echo IncorrectArguments
if %FileNotFound% == 1 echo FileNotFound
if %IncorrectCfg% == 1 echo IncorrectConfiguration
if %InvalidSolution% == 1 echo IncorrectCfg
if %IncorrectExtension% == 1 echo IncorrectExtension
if %IncorrectLicense% == 1 echo IncorrectLicense
if %AnalysisDiff% == 1 echo AnalysisDiff
if %SuppressFail% == 1 echo SuppressFail
if %LicenseRenewal% == 1 echo LicenseRenewal

Коды возврата pvs-studio-dotnet (Linux / macOS)

Примечание. Так как максимальное значение кода возврата под Unix ограничено 255, коды возврата утилит PVS-Studio_Cmd (где может возвращаться значение больше 255) и pvs-studio-dotnet отличаются.

Рассмотрим далее все возможные коды состояния утилиты, из которых формируется битовая маска кода возврата.

  • '0' - анализ успешно завершён, ошибок в проверяемом коде не найдено;
  • '1' - некорректная или просроченная лицензия на анализатор;
  • '2' - общая ошибка при работе анализатора. Эта ошибка включает пропущенные аргументы командной строки, некорректный solution или проект, заданный для анализа, ошибки внутри анализатора и т.п. Если ошибка сопровождается stack trace, пожалуйста, помогите нам улучшить анализатор и пришлите этот stack trace нам;
  • '4' - показывает, что лицензия на анализатор истечёт в течение месяца;
  • '8' - в проверяемом коде найдены потенциальные ошибки;

Запуск анализа из командной строки для C/C++ проектов, не использующих сборочную систему Visual Studio

Примечание. Данный раздел актуален для Windows. Анализ C++ проектов на Linux / macOS описан в соответствующем разделе документации.

Если ваш C/C++ проект не использует стандартные сборочные системы Visual Studio (VCBuild/MSBuild) или даже использует собственную сборочную систему / make-файлы через NMake проекты Visual Studio, то вы не сможете проверить такой проект с помощью PVS-Studio_Cmd.

В таком случае вы можете воспользоваться системой отслеживания компиляторов, которая позволяет анализировать проекты, независимо от их сборочной системы, "перехватывая" запуск процессов компиляции. Система отслеживания компиляции может использоваться как из командной строки, так и через пользовательский интерфейс приложения C and C++ Compiler Monitoring UI.

Также вы можете напрямую встроить запуск command line ядра анализатора непосредственно в вашу сборочную систему. Заметьте, что это потребует прописывать вызов ядра анализатора PVS-Studio.exe для каждого компилируемого файла, по аналогии с тем, как вызывается C++ компилятор.

Влияние настроек PVS-Studio на запуск из командной строки; фильтрация и преобразование результатов анализа (plog\json файла)

При запуске анализа кода из командной строки по умолчанию используются те же настройки, что и при запуске анализа из IDE (Visual Studio / Rider). Также можно указать, какой файл настроек использовать, с помощью аргумента --settings, как было описано выше.

Что касается, к примеру, системы фильтров (Keyword Message Filtering и Detectable Errors), то она НЕ применяется при анализе из командной строки. В том смысле, что в файле отчета независимо от заданных параметров будут все сообщения об ошибках. Но при загрузке файла с результатами в IDE фильтры уже будут применены. Это происходит из-за того, что фильтры применяются динамически к результатам (и при запуске из IDE также). Это очень удобно, поскольку, получив список сообщений, вы можете захотеть отключить некоторые из них (например, V201). Достаточно отключить их в настройках и соответствующие сообщения пропадут из списка БЕЗ перезапуска анализа.

Формат отчёта анализатора не предназначен для прямого отображения или чтения человеком. Однако, если необходимо каким-либо образом отфильтровать результаты анализа и преобразовать их в "читаемый" вид, можно воспользоваться утилитой PlogConverter, распространяемой вместе с PVS-Studio.

Для работы с отчётами разных форматов требуется использование разных утилит:

  • .plog – PlogConverter.exe (доступна только на Windows);
  • .json – plog-converter (Linux, macOS).

Исходный код обеих утилит открыт и доступен для загрузки: PlogConverter; plog-converter, что позволяет достаточно просто добавлять поддержку новых форматов на основе существующих алгоритмов.

Более подробно данные утилиты описываются в соответствующих разделах документации:

Система мониторинга компиляции в PVS-Studio

Введение

Система мониторинга компиляции (PVS-Studio Compiler Monitoring, CLMonitoring) предназначена для "бесшовной" интеграции статического анализа PVS-Studio в любую сборочную систему на ОС семейства Windows, использующую для компиляции файлов один из препроцессоров, поддерживаемых command-line анализатором PVS-Studio.exe (Visual C++, GCC, Clang, Keil MDK ARM Compiler 5/6, IAR C/C++ Compiler for ARM).

Анализатору PVS-Studio.exe для корректного анализа исходных C/C++ файлов требуется промежуточный .i (intermediate) файл - результат работы препроцессора, содержащий все включённые в исходный файл заголовки и раскрытые макросы. Это требование обуславливает невозможность "просто проверить" исходные файлы на диске, т.к. помимо содержимого самих файлов, статическому анализатору требуется также информация, необходимая для генерации такого .i файла. Заметим, что PVS-Studio не содержит в себе препроцессора и при своей работе полагается на внешний.

Как следует из её названия, рассматриваемая система основана на "отслеживании" запусков компилятора во время сборки проекта, позволяя собрать всю необходимую информацию для запуска анализа (т.е. для генерации препроцессированных i файлов) на исходниках, сборка которых была отслежена. Это, в свою очередь, позволяет проанализировать проект, просто запустив его пересборку, без необходимости от пользователя как-либо модифицировать свои сборочные сценарии.

Система представлена сервером, отслеживающим компиляцию (command-line утилита CLMonitor.exe), и приложением C and C++ Compiler Monitoring UI (Standalone.exe), осуществляющим непосредственный запуск статического анализа (при необходимости использования из командной строки CLMonitor.exe может также быть использован и в качестве клиента).

В режиме работы по умолчанию система не производит анализа иерархии запущенных процессов, а отслеживает запуск всех процессов в системе. Это значит, что, если будет запущена параллельная сборка нескольких проектов, система также отследит запуски компиляторов у обоих проектов.

CLMonitor.exe также умеет отслеживать только такие запуски процессов компилятора, которые были порождены от указанного (по PID) родительского процесса. Такой режим работы предусмотрен для случая, когда в системе была запущена параллельная сборка нескольких проектов, но вам нужно отследить запуски процессов компилятора только для определённого собираемого проекта или solution'а. Режим отслеживания дочерних процессов будет описан ниже.

Принцип работы

Сервер мониторинга (CLMonitor.exe) отслеживает запуск процессов, соответствующих целевому компилятору (например, cl.exe в случае Visual C++ или g++.exe в случае GCC) и собирает информацию об окружении этих процессов. Сервер мониторинга отслеживает запуски процессов только для того пользователя, из-под которого он сам запущен. Эта информация необходима для последующего запуска статического анализа и включает в себя:

  • рабочую директорию процесса;
  • полную строку запуска процесса (т.е. имя исполняемого файла и все аргументы, с которыми он был запущен);
  • полный путь до исполняемого файла процесса;
  • системные переменные окружения процесса.

После завершения сборки проекта серверу мониторинга (CLMonitor.exe) необходимо послать сигнал о прекращении отслеживания. Это можно сделать как с помощью того же CLMonitor.exe, запустив его в режиме клиента, так и через интерфейс Compiler Monitoring UI.

По завершении мониторинга, сервер, используя собранную о процессах информацию, запускает генерацию промежуточных (intermediate) файлов для исходных файлов, которые были скомпилированы во время работы мониторинга. Затем уже выполняется запуск непосредственно статического анализатора (PVS-Studio.exe), выдавая на выход стандартный отчёт о работе PVS-Studio, с которым можно работать как из Compiler Monitoring UI, так и из любого IDE плагина PVS-Studio.

Использование CLMonitor.exe

Примечание: далее будет описано использование CLMonitor.exe для интеграции анализа в автоматизированную систему сборки. Если вы хотите просто проверить свой проект, то воспользуйтесь приложением Compiler Monitoring UI.

CLMonitor.exe представляет собой сервер мониторинга, который осуществляет непосредственно само отслеживание запусков компиляторов. Его необходимо запустить непосредственно перед началом сборки вашего проекта. В режиме отслеживания сервер будет перехватывать запуски всех поддерживаемых компиляторов.

Перечислим далее поддерживаемые компиляторы:

  • компиляторы семейства Microsoft Visual C++ (cl.exe);
  • C/C++ компиляторы из GNU Compiler Collection (gcc.exe, g++.exe) и их производные;
  • компилятор Clang (clang.exe) и его производные.
  • Keil MDK ARM Compiler 5/6
  • IAR C/C++ Compiler for ARM
  • Texas Instruments ARM Compiler
  • GNU Arm Embedded Toolchain

Но если вы хотите интегрировать анализ непосредственно в вашу сборочную систему (или систему непрерывной интеграции и т.п.), вы не можете "просто" запустить сервер мониторинга, т.к. данный процесс на время своей работы блокирует остальную сборку. Поэтому вам нужно запустить CLMonitor.exe с аргументом monitor:

CLMonitor.exe monitor

В этом режиме CLMonitor запустит сам себя в режиме отслеживания и завершит свою работу, а ваша сборочная система сможет продолжить выполнять свои оставшиеся задачи. При этом второй (запущенный из первого) процесс CLMonitor будет оставаться запущенным и производить отслеживание сборки.

Т.к. в таком режиме работы ни одна консоль не подключена к процессу CLMonitor, то, помимо стандартных потоков ввода\вывода (stdin\stdout), сервер мониторинга также выводит свои сообщения в журнал событий Windows (Event Logs -> Windows Logs -> Application).

Также можно отслеживать только те запуски компиляторов, которые были порождены от определённого указанного по PID процесса. Для этого необходимо запустить CLMonitor.exe в режиме отслеживания с аргументами trace и --parentProcessID ('-p' сокращённый вариант). Аргумент --parentProcessID в качестве параметра должен принимать PID процесса, который, как предполагается, будет выступать родительским для запускаемых процессов компилятора. Строка запуска СLMonitor.exe в таком режиме может выглядеть следующим образом:

CLMonitor.exe trace –-parentProcessID 10256

Если вы выполняете сборку из консоли и хотите, чтобы CLMonitor.exe отследил только сборку, запускаемую из этой же консоли, то вы можете запустить CLMonitor.exe с аргументом --attach (-a):

CLMonitor.exe monitor –-attach

В таком режиме работы программа отследит только те запуски компиляторов, которые были дочерними по отношению к процессу консоли, из под которой была запущена сборка.

Стоит учитывать, что при сборке проектов, использующих сборочную систему MSBuild, оставшиеся с момента выполнения предыдущих сборок процессы MSbuild.exe не всегда завершаются. В этом случае, CLMonitor.exe запускаемый в режиме отслеживания дочерних процессов, не сможет отследить запуски компиляторов, которые были порождены от оставшихся в системе работающих процессов MSBuild.exe, так как данные процессы MSBuild.exe, скорее всего, не входят в иерархию процесса указанного с помощью аргумента --parentProcessID. В связи с этим, перед запуском CLMonitor.exe в режиме отслеживания дочерних процессов рекомендуется завершать процессы MSBuild.exe, оставшиеся в системе с момента выполнения предыдущей сборки.

Примечание: для корректной работы сервера отслеживания он должен быть запущен с правами, эквивалентными правам, с которыми запускаются и сами процессы компиляторов.

Для корректной записи сообщений в системные журналы событий процесс CLMonitor.exe необходимо запустить от имени администратора хотя бы один раз. Если процесс ни разу не стартовал с правами администратора, сообщения об ошибках не будут попадать с системный журнал.

Обратите внимание, что в системные логи сервер записывает только сообщения об ошибках в своей работе (обработанных исключениях), а не диагностические сообщения от анализатора!

После завершения сборки запустите CLMonitor.exe в режиме клиента для генерации препроцессированных файлов и непосредственного запуска статического анализа:

CLMonitor.exe analyze -l "c:\ptest.plog"

В качестве параметра '-l' предаётся полный путь до файла, в который будут записаны непосредственные результаты работы статического анализатора.

После запуска в режиме клиента CLMonitor.exe подключится к запущенному ранее серверу и получит от него информацию обо всех отловленных процессах компиляторов, после чего сервер завершит свою работу. Клиент же начнёт запуск препроцессоров и анализаторов PVS-Studio.exe для всех отслеженных исходных файлов.

В результате работы CLMonitor.exe будет получен файл-отчёта (C:\ptest.plog), который можно открыть в любом IDE плагине PVS-Studio или в Compiler Monitoring UI (PVS-Studio|Open/Save|Open Analysis Report).

Вы можете использовать в CLMonitor подавление сообщений анализатора с помощью аргумента '-u':

CLMonitor.exe analyze -l "c:\ptest.plog" -u "c:\ptest.suppress" -s

В параметре '-u' передаётся путь до suppress файла, полученного с помощью диалога Message Suppression в Compiler Monitoring UI (Tools|Message Suppression...). Параметр '-s' является необязательным и позволяет дописывать в переданный через '-u' suppress файл все новые сообщения текущей проверки.

Для задания дополнительных параметров отображения и фильтрации сообщений вы можете передать путь до файла конфигурации диагностик (.pvsconfig) с помощью аргумента '-c':

CLMonitor.exe analyze -l "c:\ptest.plog" -c "c:\filter.pvsconfig"

Сохранение дампа мониторинга компиляции и запуск анализа из дампа

CLMonitor.exe позволяет сохранить отловленную информацию о компиляции в отдельном дамп-файле. Это позволит в дальнейшем перезапустить анализ без необходимости повторно собирать проект и мониторить эту сборку. Для сохранения дампа мониторинга компиляции нужно сначала запустить мониторинг в обычном режиме командами trace или monitor, как было описано выше. После того, как сборка завершена, можно завершить мониторинг и сохранить файл дампа. Для этого нужно запустить CLMonitor.exe с командой saveDump:

CLMonitor.exe saveDump -d c:\monitoring.zip

Также можно завершить мониторинг, сохранить файл дампа и запустить анализ отловленных файлов. Это можно сделать, дополнительно указав команде CLMonitor.exe analyze путь до места сохранения дампа:

CLMonitor.exe analyze -l "c:\ptest.plog" -d c:\monitoring.zip

Запустить анализ из уже готового dump файла можно без предварительного запуска мониторинга:

CLMonitor.exe analyzeFromDump -l "c:\ptest.plog" 
-d c:\monitoring.zip

Файл дампа представляет собой обычный zip архив, содержащий список отловленных у процессов параметров (параметры запуска, текущая директория, переменные окружения и т.п.) в формате XML. Команда analyzeFromDump поддерживает запуск как из заархивированного в zip дампа, так и из неупакованного XML файла.

Использование системы отслеживания компиляции из приложения C and C++ Compiler Monitoring UI

Для "ручной" проверки отдельных проектов через CLMonitor можно воспользоваться интерфейсом приложения Compiler Monitoring UI, который можно запустить из меню Start.

Для запуска отслеживания откройте диалог через Tools -> Analyze Your Files... (рисунок 1):

https://import.viva64.com/docx/manual/CLMonitoring_ru/image1.png

Рисунок 1 - Диалог запуска мониторинга сборки

Нажмите "Start Monitoring". После этого будет запущен CLMonitor.exe, а основное окно среды будет свёрнуто.

Выполните сборку, а по её завершении нажмите на кнопку "Stop Monitoring" в окне в правом нижнем углу экрана (рисунок 2):

https://import.viva64.com/docx/manual/CLMonitoring_ru/image2.png

Рисунок 2 - Диалог управления мониторингом

Если серверу мониторинга удалось отследить запуски компиляторов, будет запущен статический анализ исходных файлов. По окончании вы получите обычный отчёт о работе PVS-Studio (рисунок 3):

https://import.viva64.com/docx/manual/CLMonitoring_ru/image3.png

Рисунок 3 - Результаты работы сервера мониторинга и статического анализатора

Результаты работы могут быть сохранены в виде XML файла (файла с расширением plog) с помощью команды меню File -> Save PVS-Studio Log As...

Использование системы отслеживания компиляции из Visual Studio

Удобная навигация по сообщениям анализатора и навигации по коду среды доступна в среде разработке Visual Studio с помощью плагина PVS-Studio. Если проверяемый проект можно открывать в Visual Studio, но при этом "обычная" проверка (PVS-Studio|Check|Solution) не работает (например, это актуально для makefile проектов), можно использовать преимущества работы из IDE, загрузив полученные результаты анализа (plog файл) в PVS-Studio с помощью команды (PVS-Studio|Open/Save|Open Analysis Report...). Данное действие можно также автоматизировать с помощью средств автоматизации Visual Studio, привязав его, а также саму проверку, например, к сборке проекта. Приведём в качестве примера интеграцию анализа с помощью системы отслеживания вызовов компилятора PVS-Studio в makefile проект. Такой тип проектов, например, используется системой сборки Unreal Engine проектов на Windows.

В качестве команды запуска сборки впишем файл run.bat:

https://import.viva64.com/docx/manual/CLMonitoring_ru/image5.png

Рисунок 4 - настройка сборки makefile проекта

Содержимое файла run.bat:

set slnPath=%1
set plogPath="%~2test.plog"
"%ProgramFiles(X86)%\PVS-Studio\CLMonitor.exe" monitor
waitfor aaa /t 10 2> NUL
nmake
"%ProgramFiles(X86)%\PVS-Studio\CLMonitor.exe" analyze -l %plogPath%
cscript LoadPlog.vbs %slnPath% %plogPath%

В качестве параметров в run.bat мы передаём пути до solution'а и проекта. Мы запускаем отслеживание запусков компиляторов с помощью CLMonitor.exe. Команда waitfor нужна для создания задержки между запуском отслеживания компиляторов и запуском сборки - без неё мониторинг может "не успеть" отловить первые запуски компиляторов. Далее мы запускаем сборку проекта через nmake. По завершению сборки мы запускаем анализ, и когда анализ завершится (результат анализа будет записан рядом с проектным файлом), мы загрузим результаты анализа в Visual Studio с помощью другого скрипта - LoadPlog.vbs. Вот его содержимое:

Set objArgs = Wscript.Arguments
Dim objSln
Set objSln = GetObject(objArgs(0))
Call objSln.DTE.ExecuteCommand("PVSStudio.OpenAnalysisReport",
    objArgs(1))

Здесь мы используем команду автоматизации Visual Studio DTE.ExecuteCommand для обращения из командной строки напрямую к запущенному экземпляру Visual Studio, в котором открыт наш проект. Фактически, выполнение данной команды эквивалентно клику по PVS-Studio|Open/Save|Open Analysis Report...

Для нахождения запущенного экземпляра Visual Studio мы использовали метод GetObject. Обратите внимание, что это метод идентифицирует запущенную Visual Studio по открытому в ней solution'у - при его использовании не следует держать открытыми несколько IDE с одинаковыми загруженными solution'ами - он может "промахнуться", и результаты анализа откроются не в той IDE, в которой вы запускали сборку\анализ.

Особенности мониторинга сборки проектов в среде IAR Embedded Workbench for ARM

При сборке проекта в среде IAR Embedded Workbench, текущая рабочая директория процесса компилятора(iccarm.exe) в некоторых случаях может быть установлена средой в C:\Windows\System32. Такое поведение может вызывать проблемы, так как CLMonitoring сохраняет промежуточные файлы в текущей рабочей директории процесса компилятора.

Чтобы избежать записи промежуточных файлов в C:\Windows\System32, а также ошибок, связанных с недостаточными правами для записи в C:\Windows\System32, необходимо открывать рабочее пространство(workspace) двойным щелчком мыши на файле с расширением eww из проводника Windows. В этом случае промежуточные файлы будут сохранены в директории рабочего пространства.

Инкрементальный анализ

В случае необходимости инкрементального анализа при использовании системы мониторинга компиляции, достаточно "отслеживать" инкрементальную сборку, т.е. компиляцию тех файлов, которые были изменены с момента последней сборки. Этот сценарий использования позволит анализировать только изменённый/новый код.

Такой сценарий использования естественен для системы мониторинга компиляции. Соответственно, режим анализа (полный или анализ только модифицированных файлов) зависит только от того, какая сборка отслеживается - полная или инкрементальная.

Заключение

Несмотря на удобство используемой в данном режиме работы "бесшовной" интеграции анализа в автоматизированный сборочный процесс (через CLMonitor.exe), тем не менее, необходимо помнить и о естественных ограничениях, присущих данному режиму - а именно, о невозможности на 100% гарантировать перехват всех запусков компилятора при сборке, что, в свою очередь, может быть вызвано как влиянием внешнего окружения (например, антивирусами), так и особенностями аппаратно - программного окружения (например, компилятор может отработать слишком быстро при использовании SSD диска, а при этом производительности CPU может оказаться недостаточно для того, чтобы "успеть" отловить такой запуск).

Поэтому мы рекомендуем, по возможности, выполнить полноценную интеграцию статического анализатора PVS-Studio.exe в вашу сборочную систему (если вы используете сборочную систему, отличную от MSBuild), либо же воспользоваться IDE плагином PVS-Studio.

Прямая интеграция анализатора в системы автоматизации сборки (C/C++)

Мы рекомендуем всем использовать PVS-Studio из сред разработки Microsoft Visual Studio, куда инструмент прекрасно интегрируется. Однако, бывают ситуации, когда необходим запуск из командной строки, например, для кроссплатформенных проектов, использующих сборочную систему, основанную на makefile'ах.

В случае, если у вас есть файлы проектов (.vcproj/.vcxproj) и решения (.sln), и запуск из командной строки нужен, к примеру, для ежедневных проверок, то рекомендуем ознакомиться со статьей "Проверка Visual C++ (.vcxproj) и Visual C# (.csproj) проектов из командной строки с помощью PVS-Studio".

Также, независимо от сборочной системы, вы можете воспользоваться системой отслеживания вызовов компилятора.

Независимый режим работы анализатора PVS-Studio

Итак, как работает С++ анализатор кода (PVS-Studio или любой другой)?

Когда пользователь анализатора дает команду проверить какой-либо файл (например, file.cpp), то анализатор сначала выполняет препроцессирование этого файла. В результате раскрываются все макросы, подставляются #include-файлы. Препроцессированный i-файл уже может разбирать анализатор кода. Обратите внимание, что анализатор не может разбирать файл, который не был препроцессирован. Поскольку тогда он не будет иметь информации об используемых типах, функциях, классах. Работа любого анализатора кода состоит как минимум из двух этапов: препроцессирование и собственно анализ.

Возможна ситуация, в которой программы не имеют связанных с ними проектных файлов, например, в случае мультиплатформенного ПО или старых проектов, собираемых с помощью пакетных утилит командной строки. Зачастую в таких случаях для управления сборочным процессом используют различные Make системы, например, Microsoft NMake, GNU Make и т.п.

Для проверки подобных проектов потребуется встроить в сборочный процесс прямой вызов анализатора (по умолчанию, файл расположен в %programfiles%\PVS-Studio\x64\PVS-Studio.exe) и передать ему все необходимые для препроцессирования аргументы. Фактически анализатор необходимо вызывать для тех же файлов, для которых вызывается компилятор (cl.exe в случае Visual C++).

Анализатор PVS-Studio должен быть вызван в пакетном режиме для каждого C/C++ файла проекта либо для целой группы файлов (файлы с расширением c/cpp/cxx и т.п., анализатор не нужно вызывать для заголовочных h файлов) с аргументами следующего вида:

PVS-Studio.exe --cl-params %ClArgs%
--source-file %cppFile% --cfg %cfgPath% --output-file %ExtFilePath%

%ClArgs% — все аргументы, передаваемые используемому компилятору при обычной компиляции, в том числе и путь до файла (или файлов) с исходным кодом.

%cppFile% — путь до анализируемого C/C++ файла или пути до группы C/C++ файлов (имена файлов, разделённые пробелами)

Параметры %ClArgs% и %cppFile% должны быть переданы анализатору PVS-Studio аналогично тому, как они передаются компилятору Visual C++ , т.е. полный путь до файла должен быть передан дважды, в каждом параметре.

%cfgPath% - путь до конфигурационного файла PVS-Studio.cfg. Этот файл общий для всех C/C++ файлов, который может быть создан вручную (пример будет показан ниже).

%ExtFilePath% - необязательный параметр, путь до внешнего файла, в который будут сохранены результаты работы анализатора. Если данный параметр не указан, анализатор будет выдавать сообщения о найденных ошибках в stdout. Полученные здесь результаты анализа можно открыть в окне PVS-Studio среды Visual Studio с помощью команды PVS-Studio/Open Analysis Report (выбрав в качестве типа файла Unparsed output). Обратите внимание на то, что, начиная с версии PVS-Studio 4.52, анализатор при запуске из командной строки поддерживает работу с одним выходным файлом (--output-file) из нескольких процессов PVS-Studio.exe. Это сделано для того, чтобы, как и в обычных makefile, при компиляции можно было запускать несколько процессов анализатора. При этом выходной файл не будет перезаписан и потерян, так как используется механизм блокировок файла.

Приведём пример вызова анализатора в независимом режиме для отдельного файла с препроцессором Visual C++ (cl.exe):

PVS-Studio.exe --cl-params "C:\Test\test.cpp" /D"WIN32" /I"C:\Test\"
--source-file "C:\Test\test.cpp" --cfg "C:\Test\PVS-Studio.cfg" 
--output-file "C:\Test\test.log"

Конфигурационный файл PVS-Studio.cfg (параметр --cfg) должен содержать следующие строки:

exclude-path = C:\Program Files (x86)\Microsoft Visual Studio 10.0
vcinstalldir = C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
platform = Win32
preprocessor = visualcpp
language = C++
skip-cl-exe = no

Рассмотрим эти параметры:

  • Параметр exclude-path содержит папку, файлы из которой проверять не надо. Если не указать папку, в которой содержатся файлы Visual Studio, то анализатор выдаст сообщения на заголовочные .h-файлы, что довольно бессмысленно. Ведь поправить эти ошибки нельзя. Поэтому мы рекомендуем всегда добавлять этот путь в исключения. Параметров exclude-path может быть несколько.
  • Параметр vcinstalldir задает папку, в которой находится используемый препроцессор. Поддерживаются препроцессоры: Microsoft Visual C++ (cl.exe), Clang(clang.exe) и MinGW (gcc.exe).
  • Параметр platform показывает, какую версию компилятора использовать - Win32, x64, Itanium или ARMV4. Обычно это Win32 или x64.
  • Параметр preprocessor показывает, какой препроцессор должен находиться в vcinstalldir. Поддерживаемые значения: visualcpp, clang, gcc. В общем случае следует выбирать препроцессор в соответствии с используемым в сборочной системе компилятором.
  • Параметр language определяет версию языков C/C++ в коде проверяемого файла (--source-file), которую анализатор ожидает найти при его разборе. Возможные значения: C, C++, C++CX, C++CLI. Поскольку каждый из поддерживаемых языковых вариантов содержит специфичные ключевые слова, неправильное указание данного параметра может привести к ошибкам разбора вида V001.

Вы можете фильтровать диагностические сообщения анализатора с помощью опций analyzer-errors и analysis-mode (заданных или в cfg-файле, или в командной строке). Это необязательные параметры:

  • Параметр analyzer-errors позволяет перечислить только те коды ошибок, которые интересны. Пример: analyzer-errors=V112 V111. Рекомендуем не указывать этот параметр.
  • Параметр analysis-mode позволяет управлять используемыми анализаторами. Значения: 0 - полный анализ (по умолчанию), 1 - только 64-битный анализ, 4 - только анализ общего назначения, 8 - только анализ оптимизации". Рекомендуем указывать значение 4.

Также существует возможность подать на вход анализатору готовый препроцессированный файл (i-файл), пропустив этап препроцессирования и сразу приступив к анализу. Для этого необходимо использовать параметр skip-cl-exe, указав значение yes. В этом режиме не требуется использование параметра cl-params. Вместо этого необходимо указать путь к i-файлу (--i-file) и задать тип препроцессора, использованного для создания этого i-файла. Указание пути к файлу исходного кода (--source-file) также необходимо. Несмотря на то, что i-файл уже содержит достаточную информацию для анализа, иногда может потребоваться сравнение i-файла с файлом исходного кода, например, когда анализатору требуется посмотреть на нераскрытый макрос. Таким образом, вызов анализатора в независимом режиме с заданным i-файлом для препроцессора Visual C++ (cl.exe) мог бы иметь вид:

PVS-Studio.exe --source-file "C:\Test\test.cpp"
--cfg "C:\Test\PVS-Studio.cfg" --output-file "C:\Test\test.log"

Конфигурационный файл PVS-Studio.cfg (параметр --cfg) должен содержать следующие строки:

exclude-path = C:\Program Files (x86)\Microsoft Visual Studio 10.0
vcinstalldir = C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\
platform = Win32
preprocessor = visualcpp
language = C++
skip-cl-exe = yes
i-file = C:\Test\test.i

Полный список параметров командной строки можно получить с помощью запуска:

PVS-Studio.exe –help

Следует отметить, что при явном вызове PVS-Studio.exe, лицензионная информация, сохранённая в файле 'Settings.xml', не учитывается. При запуске следует явно указывать путь до файла с лицензией. Это текстовый файл в кодировке UTF-8, состоящий из двух строк – имени и ключа.

Путь до файла с лицензией можно указать как в конфигурационном файле PVS-Studio, так и передать как аргумент командной строки. Соответствующий параметр: lic-file.

Например, чтобы указать путь до файла с лицензией в .cfg файле, следует добавить следующую строку:

lic-file = D:\Test\license.lic

Использование режима независимого запуска анализатора на примере Makefile проекта

Возьмём для примера Makefile проект, в котором сборка осуществляется компилятором Visual C++, и она описана в makefile проекта следующим правилом:

$(CC) $(CFLAGS) $<

Здесь $(CC) вызывает cl.exe, которому передаются параметры компиляции $(CFLAGS), и наконец с помощью макроса $< осуществляется подстановка всех С\С++ файлов, от которых зависит текущая цель сборки. Таким образом, для всех файлов с исходным кодом будет вызван компилятор cl.exe с необходимыми параметрами.

Модифицируем данный сценарий таким образом, чтобы перед вызовом компилятора для каждого файла осуществлялась проверка статическим анализатором PVS-Studio:

$(PVS) --source-file $< --cl-params $(CFLAGS) $<
--cfg "C:\CPP\PVS-Studio.cfg"
$(CC) $(CFLAGS) $<

Здесь $(PVS) - путь до исполняемого файла анализатора (%programfiles%\PVS-Studio\x64\PVS-Studio.exe). Обратите внимание, что после вызова анализатора на следующей строке вызывается компилятор Visual C++ с теми же параметрами, что и изначально. Это делается для того, чтобы были построены правильные цели (targets) и сборка не остановился из-за отсутствия .obj-файлов.

Работа с результатами анализа, полученными при использовании режима запуска из командной строки

Инструмент PVS-Studio разрабатывался для работы в рамках сред Visual Studio. И его работа из командной строки - это дополнение к основному режиму работы. Тем не менее, все его диагностические возможности доступны.

Полученные в данном режиме ошибки могут быть также перенаправлены в файл с помощью аргумента командной строки --output-file. Данный файл будет содержать необработанный и неотфильтрованный вывод анализатора.

Такой файл можно открыть в IDE окне PVS-Studio или приложении C and C++ Compiler Monitoring UI (Standalone.exe) командой Open Analysis Report (выбрав в качестве типа файла 'Unparsed output') и в дальнейшем его можно будет сохранить в стандартном формате отчета PVS-Studio log file (plog), что позволит избежать дублирования сообщений, а также использовать все стандартные механизмы фильтрации сообщений.

Также 'сырой' отчёт можно преобразовать в один из поддерживаемых форматов (xml, html, csv и т.п.) с помощью консольной утилиты PlogConverter.

Инкрементальный анализ в версии для командной строки

Пользователи, знакомые с режимом инкрементального анализа в PVS-Studio, при работе из IDE естественно не хотят от него отказываться и в версии для командной строки. К счастью, любая система сборки автоматически позволяет получить инкрементальный анализ "из коробки". Ведь говоря "make" мы компилируем только изменившиеся файлы. Соответственно и PVS-Studio.exe будет вызван только для изменившихся файлов. Так что инкрементальный анализ в версии для командной строки есть автоматически.

Использование Microsoft IntelliSense в независимом режиме работы анализатора

Несмотря на то, что полученный в независимом режиме неотфильтрованный текстовый файл с диагностическими сообщениями анализатора возможно открыть в окне PVS-Studio среды разработки (что в свою очередь позволит использовать навигацию по файлам и механизмы фильтрации), в самой среде Visual Studio будет работать фактически только текстовый редактор, а дополнительная функциональность системы IntelliSense (автодополнение, переход к местам декларации типов и телам функций, и т.п.) будет недоступна. А это, в свою очередь, создаёт очень большие неудобства при работе с результатами анализа, особенно для крупных проектов, вынуждая каждый раз вручную искать объявления классов и функций и значительно увеличивая время работы над каждым диагностическим сообщением.

Решить рассматриваемую проблему можно, создав пустой проект Visual C++ (например, Makefile проект) в одной директории с проверяемыми анализатором исходными C++ файлами (vcproj/vcxproj файл при этом должен находиться в папке, являющейся корневой для всех проверяемых исходных файлов). После этого можно включить режим Show All Files проекта (кнопка Show All Files в окне Solution Explorer), что позволит увидеть в древовидной структуре окна Solution Explorer все файлы, располагающиеся в нижележащих директориях файловой системы. Затем через контекстную команду Include in Project можно добавить в проект все необходимые cpp, с и h файлы (возможно, что для некоторых файлов также придётся прописать пути до include директорий, если в них, например, присутствуют включения из сторонних библиотек). Стоит помнить, что при включении в проект лишь части от всех проверяемых файлов, IntelliSense может не распознать часть из упоминаемых в них типов, если эти типы определяются как раз в отсутствующих файлах.

https://import.viva64.com/docx/manual/PVS-Studio_command-line_ru/image1.png

Рисунок 1 — добавление файлов в проект

Созданный таким образом проектный файл Visual C++ не может быть использован для сборки или анализа исходного кода с помощью PVS-Studio, но всё же позволит значительно упростить работу с результатами анализа, и может быть сохранён для дальнейшего использования на следующих итерациях работы анализатора в независимом режиме.

Разница в поведении консольной версии PVS-Studio.exe при обработке одного файла и при обработке нескольких файлов

Как известно, компилятор cl.exe может обрабатывать файлы как по одному, так и группой. В первом случае вызов компилятора происходит в несколько запусков:

cl.exe ... file1.cpp
cl.exe ... file2.cpp
cl.exe ... file2.cpp

Во втором случае - за один запуск:

cl.exe ... file1.cpp file2.cpp file3.cpp

И тот, и другой режим работы поддерживается в консольной версии PVS-Sudio.exe, примеры приведены выше.

Пользователю может оказаться полезно понимать логику работы программы в первом и втором случае. При раздельном запуске PVS-Studio.exe для каждого файла сначала вызывает препроцессор, а затем выполняется анализ. При обработке нескольких файлов за раз PVS-Studio.exe сначала выполняет препроцессирование всех файлов, а затем для каждого файла еще раз запускается PVS-Studio.exe для анализа уже препроцессированных файлов.

Проверка Unreal Engine проектов

В данном разделе рассматривается проверка Unreal Engine проектов на операционной системе Windows. Инструкции по проверке проектов на Linux\macOS доступны по данной ссылке.

Интеграция с Unreal Build System доступна только для Enterprise лицензии PVS-Studio. Вы можете запросить пробную Enterprise лицензию на странице загрузки.

Для сборки проектов для Unreal Engine используется специализированная сборочная система Unreal Build System. Данная система интегрируется поверх сборочной системы, используемой средой Visual Studio (MSBuild), с помощью автогенерируемых makefile проектов MSBuild. Это специальный тип Visual C++ (vcxproj) проектов, в которых для непосредственного выполнения сборки выполняется команда, вызывающая стороннюю утилиту, например, (но далеко не обязательно) Make. Использование makefile проектов позволяет работать с кодом Unreal Engine из среды Visual Studio, используя такие преимущества, как автодополнение, подсветка синтаксиса, навигация по символам и т.п.

В связи с тем, что makefile проекты MSBuild сами по себе не содержат полной информации, необходимой для компиляции, а, следовательно, и препроцессирования исходных C/C++ файлов, PVS-Studio не поддерживает проверку таких проектов с помощью Visual Studio плагина или консольной утилиты PVS-Studio_Cmd.exe. Поэтому, для проверки таких проектов с помощью PVS-Studio можно пойти двумя путями - отслеживание вызовов компилятора (Compiler Monitoring) и прямая интеграция C/C++ анализатора PVS-Studio.exe в сборочную утилиту Unreal Build Tool. Рассмотрим эти варианты подробнее.

Проверка с помощью отслеживания вызовов компилятора

Для сборки на Windows Unreal Build System использует компилятор Visual C++ - cl.exe. Этот компилятор поддерживается системой отслеживания компиляторов PVS-Studio на Windows. Эту систему можно использовать как из приложения C and C++ Compiler Monitoring UI (Standalone.exe), так и с помощью консольной утилиты CLMonitor.exe.

Запуск мониторинга компиляций можно осуществлять вручную из приложения Compiler Monitoring UI, или назначить на событие начала\окончания сборки в Visual Studio. Результатом работы системы мониторинга является XML файл отчёта plog, который можно открыть в Visual Studio плагине PVS-Studio, или преобразовать к одному из стандартных форматов (txt, html, csv) с помощью специальной утилиты PlogConverter.

Подробное описание системы отслеживания вызовов компилятора доступно в данном разделе документации. Мы рекомендуем использовать данный способ запуска анализа для знакомства с анализатором, как наиболее простой в настройке.

Проверка с помощью интеграции в Unreal Build Tool

Общее описание прямого встраивания C/C++ анализатора в любую сборочную систему доступно здесь.

В случае с Unreal Build System, разработчики из Epic Games предоставляют возможность использовать PVS-Studio с помощью интеграции со сборочной утилитой Unreal Build Tool, начиная с версии 4.17.

Перед началом анализа вам будет необходимо ввести лицензию на анализатор. Откройте Visual Studio, и в окне 'PVS-Studio|Options...Registration' введите ваши данные (обратите внимание, что в до версии Unreal Engine 4.20, UBT не умел подхватывать лицензию из общего файла настроек PVS-Studio. В случае, если UBT не видит лицензию, введённую через интерфейс, вам необходимо создать отдельный файл лицензии с именем PVS-Studio.lic вручную и подложить его в директорию '%USERPROFILE%\AppData\Roaming\PVS-Studio').

Unreal Build Tool позволяет запускать анализ PVS-Studio, добавив данный флаг в строку запуска:

-StaticAnalyzer=PVSStudio

Например, полная строка запуска Unreal Build Tool может выглядеть так:

UnrealBuildTool.exe UE4Client Win32 Debug -WaitMutex -FromMsBuild 
    -StaticAnalyzer=PVSStudio -DEPLOY

Для включения анализа при запуске из Visual Studio, откройте свойства проекта 'Properties|Configuration Properties|NMake' и добавьте флаг -StaticAnalyzer=PVSStudio в опции сборки и пересборки (Build Command Line / Rebuild All Command Line).

Примечание. Обратите внимание, что при таком сценарии использования будет выполнен только анализ - сборка проведена не будет.

Примечание 2. Интеграция PVS-Studio с Unreal Build Tool поддерживает не все настройки анализатора, доступные из Visual Studio (PVS-Studio|Options...). В данный момент поддерживается выбор групп диагностик для анализа, добавление директорий-исключений через 'PVS-Studio|Options...|Don't Check Files' и фильтрация загруженных результатов анализа через 'Detectable Errors'.

Модификация сборочных скриптов для сборки и анализа

Если вам требуется настроить одновременную сборку и анализ в рамках одной конфигурации Visual Studio, то для этого можно создать вспомогательные скрипты (в нашем примере назовём их, соответственно, BuildAndAnalyze и RebuildAndAnalyze) на основе стандартных скриптов Build и Rebuild.

Основное изменение в скрипте RebuildAndAnalyze - вызов для сборки нового скрипта BuildAndAnalyze.bat, а не Build.bat.

В скрипт BuildAndAnalyze необходимо добавить удаление кэша действий и запуск UnrealBuildTool с флагом анализа после проведения успешной сборки.

В кэш сохраняются действия, выполняемые UBT в ходе работы (сборки, анализ и т.п.).

Удаление кэша перед анализом необходимо для того, чтобы не сохранять действия анализа, что позволит провести повторный полный анализ. В случае, если действия анализа закэшируются, при повторном его проведении будет выполнен некий аналог инкрементального анализа (будут проанализированы только изменённые файлы), но в результирующий отчёт анализатора всё равно попадут предупреждения из всех логов (и вновь полученных, и старых). При этом, если, например, анализ будет проведён обновлённой версией анализатора, в которой добавлены новые диагностические правила, то немодифицированные файлы проверены новой версией анализатора всё равно не будут.

Восстановление кэша из бэкапа после анализа необходимо для того, чтобы вновь получить сохранённые действия сборки. Если UBT не обнаружит сохранённых действий сборки - она будет выполнена заново.

Удаление/восстановление кэша необходимо для того, чтобы не сохранять результаты анализа (чтобы иметь возможность заново провести полный анализ), но при этом и не потерять действия по сборке проекта.

Примечание. Изменения, описанные ниже, основываются на стандартном скрипте Build и стандартной строке запуска скрипта. В случае, если используется модифицированный скрипт или нестандартный порядок аргументов, может потребоваться внесение дополнительных изменений.

Первоначально необходимо определить ряд переменных, которые будут необходимы для удаления/восстановления файла кэша действий. Операции, связанные с кэшем действий, актуальны для версий Unreal Engine 4.21 и выше.

SET PROJECT_NAME=%1%
SET PLATFORM=%2%
SET UPROJECT_FILE=%~5

SET ACTIONHISTORY_FOLDER=....
SET ACTION_HISTORY=....
SET ACTION_HISTORY_BAC=%ACTION_HISTORY%.bac
SET ACTIONHISTORY_PATH="%ACTIONHISTORY_FOLDER%\%ACTION_HISTORY%"
SET ACTIONHISTORY_BAC_PATH=
      "%ACTIONHISTORY_FOLDER%\%ACTION_HISTORY_BAC%"

Для разных версий движка во фрагменте скрипта, приведённом выше, необходимо задать различные значения переменных ACTIONHISTORY_FOLDER и ACTION_HISTORY.

Для версии 4.21 и 4.22:

SET ACTIONHISTORY_FOLDER=
      %UPROJECT_FILE%\..\Intermediate\Build\%PLATFORM%\%PROJECT_NAME%
SET ACTION_HISTORY=ActionHistory.bin

Для версии 4.23 и более новых:

SET ACTIONHISTORY_FOLDER=
     %UPROJECT_FILE%\..\Intermediate\Build\%PLATFORM%\%PLATFORM%\
     %PROJECT_NAME%
SET ACTION_HISTORY=ActionHistory.dat

После вызова UnrealBuildTool для сборки (и команды 'popd') необходимо добавить следующий код:

SET "UBT_ERR_LEVEL=!ERRORLEVEL!"
SET "NEED_TO_PERFORM_ANALYSIS="

IF "!UBT_ERR_LEVEL!"=="0" (
  SET "NEED_TO_PERFORM_ANALYSIS=TRUE"
)

IF "!UBT_ERR_LEVEL!"=="2" (
  SET "NEED_TO_PERFORM_ANALYSIS=TRUE"
)

IF DEFINED NEED_TO_PERFORM_ANALYSIS (
  pushd "%~dp0\..\..\Source"

  ECHO Running static analysis

  IF EXIST %ACTIONHISTORY_PATH% (
    ECHO Copying %ACTION_HISTORY% to %ACTION_HISTORY_BAC%
    COPY %ACTIONHISTORY_PATH% %ACTIONHISTORY_BAC_PATH%
    ECHO Removing %ACTION_HISTORY%: %ACTIONHISTORY_PATH%
    DEL  %ACTIONHISTORY_PATH%
)

  ..\..\Engine\Binaries\DotNET\UnrealBuildTool.exe 
    %* -StaticAnalyzer=PVSStudio -DEPLOY 
  popd

  IF EXIST %ACTIONHISTORY_BAC_PATH% (
    ECHO Recovering %ACTION_HISTORY%
    COPY %ACTIONHISTORY_BAC_PATH% %ACTIONHISTORY_PATH%
    ECHO Removing %ACTION_HISTORY_BAC%: %ACTIONHISTORY_BAC_PATH%
    DEL  %ACTIONHISTORY_BAC_PATH%
  )
)

Наиболее важными операциями из приведённого выше кода являются удаление и восстановление кэша, а также запуск UnrealBuildTool с флагом -StaticAnalyzer=PVSStudio для проведения анализа.

При необходимости можно использовать модифицированный скрипт при работе из среды Visual Studio. Для этого необходимо указать его в качестве используемого в свойствах проекта: Properties|Configuration Properties|NMake|Build Command Line.

Обратите внимание, что при использовании модифицированных скриптов флаг -StaticAnalyzer=PVSStudio в аргументах запуска скрипта указывать не нужно, так как он уже выставляется в скрипте при запуске UnrealBuildTool для анализа.

Включение различных групп диагностик

Включение различных групп диагностик доступно начиная с версии 4.25 Unreal Engine.

Для выбора нужных групп диагностик необходимо модифицировать target-файлы проекта.

Для использования соответствующих опций из файла настроек PVS-Studio (Settings.xml) в target-файле необходимо выставить значение 'true' для свойства 'WindowsPlatform PVS.UseApplicationSettings' (например, в конструкторе):

public MyUEProjectTarget( TargetInfo Target) : base(Target)
{
  ....
  WindowsPlatform.PVS.UseApplicationSettings = true;
}

Также необходимые группы диагностик можно включить в target-файле напрямую. Например, включить диагностики микро-оптимизаций можно следующим образом:

WindowsPlatform.PVS.ModeFlags =
  UnrealBuildTool.PVSAnalysisModeFlags.Optimizations;

Допустимые значения для включения соответствующих групп диагностик:

  • Check64BitPortability;
  • GeneralAnalysis;
  • Optimizations;
  • CustomerSpecific;
  • MISRA.

Для включения нескольких групп диагностик используйте оператор '|':

WindowsPlatform.PVS.ModeFlags =
    UnrealBuildTool.PVSAnalysisModeFlags.GeneralAnalysis
  | UnrealBuildTool.PVSAnalysisModeFlags.Optimizations;

Работа с результатами анализа

Путь до файла с результатами анализа будет выведен в Output (Build) окно Visual Studio (или stdout, если вы запускали Unreal Build Tool вручную из командной строки). Данный файл с результатами анализа имеет "нераспарсенный" вид - его можно открыть в IDE командой 'PVS-Studio|Open/Save|Open Analysis Report' и выбрав тип файла 'unparsed output', либо результаты анализа можно преобразовать с помощью утилиты PlogConverter, как это было описано в разделе выше для XML лога.

Особенности работы со списком диагностических предупреждений более подробно описаны в статье "Работа со списком диагностических сообщений", а работа с отчётом анализатора - в статье "Работа с XML отчётом (.plog файл)".

Автоматическая загрузка логов в IDE Visual Studio

Более удобным вариантом использования является автоматическая загрузка лога анализа в окно вывода PVS-Studio при работе в среде Visual Studio. Для такого сценария необходимо включить соответствующую опцию: 'PVS-Studio|Options|Specific Analyzer Settings|Save/Load (analyzer report)|AutoloadUnrealEngineLog'.

Как запустить PVS-Studio в Linux и macOS

Введение

Статический анализатор С/C++ кода PVS-Studio представляет собой консольное приложение с именем pvs-studio и несколько вспомогательных утилит. Для работы программы необходимо иметь настроенное окружение для сборки вашего проекта.

Для проверки каждого файла с кодом выполняется новый запуск анализатора. Результаты проверки множества исходных файлов могут дописываться в один отчёт анализатора, либо выводиться в stdout.

Существуют три основных режима работы анализатора:

  • Интеграция вызова pvs-studio в сборочную систему;
  • Интеграция анализатора с помощью модулей для CMake/QMake;
  • Анализ проекта без интеграции с помощью утилиты pvs-studio-analyzer.

Установка и обновление PVS-Studio

Примеры команд для установки анализатора из пакетов и репозиториев приведены на этих страницах:

Информация о файле лицензии

Вы можете запросить лицензию для знакомства с PVS-Studio через форму обратной связи.

Для сохранения информации о лицензии в файл следует воспользоваться следующей командой:

pvs-studio-analyzer credentials NAME KEY [-o LIC-FILE]

По умолчанию будет создан файл PVS-Studio.lic в директории ~/.config/PVS-Studio/. В этом случае файл лицензии можно не указывать в параметрах запуска анализатора, он будет подхвачен автоматически.

Лицензионный ключ к анализатору представляет собой текстовый файл в кодировке UTF8.

Проверить срок действия лицензии можно с помощью следующей команды:

pvs-studio --license-info /path/to/PVS-Studio.lic

Быстрый старт

Лучшим способом использования анализатора является интеграция в сборочную систему. Следует прописать вызов анализатора рядом с вызовом компилятора. Но если необходимо быстро попробовать анализатор на небольшом проекте, то можно воспользоваться утилитой pvs-studio-analyzer.

Важно. Проект должен успешно компилироваться и быть собран перед анализом.

CMake-проект

Для проверки CMake-проекта используется формат JSON Compilation Database. Для получения необходимого анализатору файла compile_commands.json необходимо добавить один флаг к вызову CMake:

cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On <src-tree-root>

CMake поддерживает генерацию JSON Compilation Database для Unix Makefiles.

Запускается анализ следующими командами:

pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic
  -o /path/to/project.log -e /path/to/exclude-path -j<N>

plog-converter -a GA:1,2 -t tasklist
  -o /path/to/project.tasks /path/to/project.log

CMake/Ninja-проект

Для проверки Ninja-проекта также используется формат JSON Compilation Database. Для получения необходимого анализатору файла compile_commands.json необходимо выполнить следующие команды:

cmake -GNinja <src-tree-root>
ninja -t compdb

Запускается анализ следующими командами:

pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic
  -o /path/to/project.log -e /path/to/exclude-path -j<N>

plog-converter -a GA:1,2 -t tasklist
  -o /path/to/project.tasks /path/to/project.log

QBS-проект

Для проверки проекта, использующего Qt Build System, необходимо выполнить следующие команды:

qbs generate --generator clangdb

Запускается анализ следующими командами:

pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic
  -o /path/to/project.log -e /path/to/exclude-path -j<N>

plog-converter -a GA:1,2 -t tasklist
  -o /path/to/project.tasks /path/to/project.log

Xcode-проект (только для macOS)

С помощью утилиты xcpretty необходимо сгенерировать JSON Compilation Database:

xcodebuild [flags] | xcpretty -r json-compilation-database

Запускается анализ следующими командами:

pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic
  -f build/reports/compilation_db.json
  -o /path/to/project.log -e /path/to/exclude-path -j<N>

plog-converter -a GA:1,2 -t tasklist
  -o /path/to/project.tasks /path/to/project.log

Любой проект (только для Linux)

Для работы этой утилиты необходим установленная утилита strace.

Собрать проект можно с помощью команды:

pvs-studio-analyzer trace -- make

Вместо команды make может быть любая команда запуска сборки проекта со всеми необходимыми параметрами, например:

pvs-studio-analyzer trace -- make debug

После сборки проекта необходимо выполнить команды:

pvs-studio-analyzer analyze -l /path/to/PVS-Studio.lic
  -o /path/to/project.log -e /path/to/exclude-path -j<N>

plog-converter -a GA:1,2 -t tasklist
  -o /path/to/project.tasks /path/to/project.log

Предупреждения анализатора будут сохранены в указанный project.tasks файл. Разные способы просмотра и фильтрации полученного отчёта приведены в разделе этого документа "Просмотр и фильтрация отчёта анализатора".

Если у вас не CMake проект или возникли проблемы с системной утилитой strace, то можно попробовать сгенерировать файл compile_commands.json с помощью утилиты Bear. Этот файл поможет анализатору успешно проверить проект только в том случае, если переменные окружения не влияют на компиляцию файлов.

Если вы используете кросс-компиляторы

В таком случае компиляторы могут иметь специальные имена и анализатор не сможет их найти. Для проверки такого проекта необходимо явно перечислить имена компиляторов без путей:

pvs-studio-analyzer analyze ... --compiler COMPILER_NAME
  --compiler gcc --compiler g++ --compiler COMPILER_NAME

plog-converter ...

Также при использовании кросс-компиляторов изменится каталог с заголовочными файлами компилятора. Чтобы анализатор не выдавал предупреждения на эти файлы, необходимо исключить такие директории из анализа с помощью флага -e:

pvs-studio-analyzer ... -e /path/to/exclude-path ...

При интеграции анализатора в сборочную систему проблем с кросс-компиляторами не возникает.

Режим инкрементального анализа

Для утилиты pvs-studio-analyzer доступен режим инкрементального анализа (анализ только изменённых файлов). Для этого необходимо запустить утилиту с параметром --incremental:

pvs-studio-analyzer analyze ... -incremental ...

Этот режим работает независимо от инкрементальной сборки проекта. Т.е. если Ваш проект полностью скомпилирован, то первый запуск инкрементального анализа всё равно будет анализировать все файлы. А при следующем запуске будут анализироваться только изменённые.

Для отслеживания изменённых файлов, анализатор сохраняет служебную информацию в каталоге с именем .PVS-Studio в директории запуска. Поэтому для использования этого режима необходимо всегда запускать анализатор в одной и той же директории.

Интеграция PVS-Studio в сборочные системы и IDE

Примеры интеграции в CMake, QMake, Makefile и WAF

Тестовые проекты доступны в официальном репозитории PVS-Studio на GitHub:

Как выглядит интеграция с CLion, QtCreator и Eclipse CDT

На рисунке 1 представлен пример просмотра предупреждений анализатора в CLion:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image1.png

Рисунок 1 - Просмотр предупреждений PVS-Studio в CLion

На рисунке 2 представлен пример просмотра предупреждений анализатора в QtCreator:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image3.png

Рисунок 2 - Просмотр предупреждений PVS-Studio в QtCreator

На рисунке 3 представлен пример просмотра предупреждений анализатора в Eclipse CDT:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image5.png

Рисунок 3 - Просмотр предупреждений PVS-Studio в Eclipse CDT

Параметры препроцессора

Анализатор проверяет не исходные файлы, а препроцессированные файлы. Такой способ позволяет проводить более глубокий и качественный анализ исходного кода.

В связи с этим, у нас есть ограничения на передаваемые параметры компиляции. К ним относятся параметры, мешающие запуску компилятора в режиме препроцессора, либо "портящие" вывод препроцессора. Ряд флажков оптимизации и отладки, например, -O2, -O3, -g3, -ggdb3 и другие, вносят изменения, "портящие" вывод препроцессора. Информация о недопустимых параметрах будет выведена анализатором при их обнаружении.

Этот факт ни в коем случае не обязывает вносить изменения в настройки проверяемого проекта, но для правильного запуска анализатора часть параметров необходимо исключить.

Конфигурационный файл *.cfg

При интеграции анализатора в сборочную систему ему необходимо передать файл с настройками (*.cfg). Имя конфигурационного файла может быть произвольным, и его необходимо передать с флагом "--cfg".

Файл настроек с именем PVS-Studio.cfg, находящийся в одной директории с исполняемым файлом анализатора, может быть загружен автоматически без передачи через параметры командной строки.

Возможные значения настроек в конфигурационном файле:

  • exclude-path (опционально) задаёт директорию, файлы из которой проверять не надо. Обычно это каталоги системных файлов или подключаемых библиотек. Параметров exclude-path может быть несколько.
  • platform (обязателен) задаёт используемую платформу. Возможные варианты: linux32 или linux64.
  • preprocessor (обязателен) задаёт используемый препроцессор. Возможные варианты: gcc, clang, keil.
  • language (обязателен) задаёт язык проверяемого файла, который анализатор ожидает найти при его разборе. Возможные значения: C, C++. Поскольку каждый из поддерживаемых языковых диалектов содержит специфичные ключевые слова, неправильное указание данного параметра может привести к ошибкам разбора кода V001.
  • lic-file (опционально) содержит абсолютный путь до файла с лицензией.
  • analysis-mode (опционально) задаёт тип выдаваемых предупреждений. Рекомендуется использовать значение "4" (General Analysis, подходит подавляющему большинству пользователей).
  • output-file (опционально) задаёт полный путь к файлу, в который будет записываться отчёт работы анализатора. При отсутствии этого параметра в конфигурационном файле все сообщения о найденных ошибках будут выводиться в консоль.
  • sourcetree-root (опционально) по умолчанию, при генерации диагностических сообщений, PVS-Studio выдаёт абсолютные, полные пути до файлов, в которых анализатор нашёл ошибки. С помощью данной настройки можно задать корневую часть пути, которую анализатор будет автоматически подменять на специальный маркер. Например, абсолютный путь до файла /home/project/main.cpp будет заменён на относительный путь |?|/main.cpp, если /home/project был указан в качестве корня.
  • source-file (обязателен) содержит абсолютный путь до проверяемого исходного файла.
  • i-file (обязателен) содержит абсолютный путь до препроцессированного файла.
  • no-noise (опционально) отключает выдачу сообщений низкого уровня достоверности (3-ий уровень). При работе на больших проектах анализатор может выдать большое число предупреждений. Используйте эту настройку, если вы не можете исправить все сообщения анализатора сразу, и вам нужно сконцентрироваться на правке наиболее важных срабатываний в первую очередь.

Важное примечание:

Не обязательно создавать новый конфигурационный файл для проверки каждого файла. В него достаточно сохранить постоянные настройки, например, lic-file и т.п.

Интеграция PVS-Studio с системами Continuous Integration

Любой из перечисленных способов интеграции анализатора в сборочную систему можно автоматизировать в системе Continuous Integration. Это можно сделать в Jenkins, TeamCity и других, настроив автоматический запуск анализа и уведомление о найденных ошибках.

Также возможна интеграция с платформой непрерывного анализа SonarQube с помощью плагина PVS-Studio. Плагин предоставляется с анализатором в .tgz архиве, доступном для загрузки. Инструкция по настройке доступна на странице: "Интеграция результатов анализа PVS-Studio в SonarQube".

Просмотр и фильтрация отчёта анализатора

Утилита Plog Converter

Для конвертации отчёта анализатора о найденных ошибках в различные форматы (*.xml, *.tasks и т.п.) можно воспользоваться утилитой Plog Converter, которая распространяется с открытым исходным кодом.

В командной строке терминала выполнить:

plog-converter [опции] <путь к файлу с логом PVS-Studio>

Все опции могут быть указаны в произвольном порядке.

Доступные опции:

  • -t - формат вывода утилиты.
  • -o - путь к файлу, в который будет осуществляться вывод. Если пропущено, вывод будет осуществляться на стандартное устройство вывода.
  • -s - путь к файлу конфигурации. Файл аналогичен файлу конфигурации анализатора PVS-Studio.cfg. Из этого файла используется информация о корне проекта и исключённых директориях (exclude-path).
  • -r - путь до директории проекта.
  • -a - набор фильтруемых диагностических правил. Полный список: GA, 64, OP, CS, MISRA. Могут использоваться в сочетании с уровнями, например: "-a GA:1,2;64:1;CS".
  • -d - список исключённых диагностик, разделённых запятыми: "-d V595,V730".
  • -m - включить отображение CWE ID и MISRA ID для найденных предупреждений: " -m cwe -m misra".
  • -e - использовать stderr вместо stdout.

Детальное описание уровней достоверности предупреждений и наборов диагностических правил приведено в разделе документации "Знакомство со статическим анализатором кода PVS-Studio".

На данный момент доступны следующие форматы:

  • xml - удобный формат для дополнительной обработки результатов анализа, поддерживается плагином для SonarQube;
  • csv - текстовый формат, предназначенный для представления табличных данных;
  • errorfile - формат вывода gcc и clang;
  • tasklist - формат ошибок, который можно открыть в QtCreator;
  • html - отчёт html с кратким описанием результатов анализа. Подходит для рассылки уведомлений электронной почтой;
  • fullhtml - отчёт html с сортировкой результатов анализа по разных параметрам и навигацией по исходному коду.

Результатом работы утилиты является файл с сообщениями в нужном формате, отфильтрованными по правилам, указанным в файле конфигурации.

Просмотр отчёта анализатора в QtCreator

Пример команды, которая подойдёт большинству пользователей для открытия отчёта в QtCreator:

plog-converter -a GA:1,2 -t tasklist
  -o /path/to/project.tasks /path/to/project.log

На рисунке 3 представлен пример просмотра .tasks файла в QtCreator:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image7.png

Рисунок 4 - Просмотр .tasks файла в QtCreator

Просмотр Html отчёта в браузере или почтовом клиенте

Конвертер отчётов анализатора позволяет генерировать Html отчёт двух видов:

1. FullHtml - полноценный отчёт для просмотра результатов анализа. Есть возможность поиска и сортировки сообщений по типу, файлу, уровню, коду и тексту предупреждения. Особенностью этого отчёта является возможность навигации к месту ошибки в файле с исходным кодом. Сами файлы с исходным кодом, на которых были предупреждения анализатора, копируются в html и являются частью отчёта. Примеры отчёта приведены на рисунках 4-5.

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image9.png

Рисунок 4 - Пример главной страницы Html отчёта

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image11.png

Рисунок 5 - Просмотр предупреждения в коде

Пример команды для получения такого отчёта:

plog-converter -a GA:1,2 -t fullhtml
  /path/to/project.log -o /path/to/report_dir

Такой отчёт удобно рассылать в архиве или предоставлять к нему доступ по локальной сети с помощью любого веб-сервера, например, Lighttpd и т.п.

2. Html - легковесный отчёт, состоящий из одного файла в формате .html. Содержит краткую информацию о найденных предупреждениях и подходит для уведомления о результатах по электронной почте. Пример отчёта приведен на рисунке 6.

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image12.png

Рисунок 6 - Пример простой Html страницы

Пример команды для получения такого отчёта:

plog-converter -a GA:1,2 -t html
  /path/to/project.log -o /path/to/project.html

Просмотр отчёта анализатора в Vim/gVim

Пример команд для открытия отчёта в редакторе gVim:

$ plog-converter -a GA:1,2 -t errorfile
  -o /path/to/project.err /path/to/project.log

$ gvim /path/to/project.err
:set makeprg=cat\ %
:silent make
:cw

На рисунке 7 представлен пример просмотра .err файла в gVim:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image14.png

Рисунок 7 - Просмотр .err файла в gVim

Просмотр отчёта анализатора в GNU Emacs

Пример команд для открытия отчёта в редакторе Emacs:

plog-converter -a GA:1,2 -t errorfile
  -o /path/to/project.err /path/to/project.log

emacs
M-x compile
cat /path/to/project.err 2>&1

На рисунке 8 представлен пример просмотра .err файла в Emacs:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image15.png

Рисунок 8 - Просмотр .err файла в Emacs

Просмотр отчёта анализатора в LibreOffice Calc

Пример команд для конвертации отчёта в CSV формат

plog-converter -a GA:1,2 -t csv
  -o /path/to/project.csv /path/to/project.log

После открытия файла project.csv в LibreOffice Calc необходимо добавить автофильтр: Menu Bar --> Data --> AutoFilter. На рисунке 9 представлен пример просмотра .csv файла в LibreOffice Calc:

https://import.viva64.com/docx/manual/PVS-Studio_Linux_ru/image16.png

Рисунок 9 - Просмотр .csv файла в LibreOffice Calc

Файл конфигурации

Более объёмные настройки можно сохранить в файл конфигурации со следующими опциями:

  • enabled-analyzers - опция, аналогичная опции -a в параметрах консольной строки.
  • sourcetree-root - строка, задающая путь к корню исходных файлов проверяемого проекта. Если указана неправильно, дальнейшая работа с результатом работы утилиты будет затруднена.
  • errors-off - глобально выключенные номера предупреждений, перечисленные через пробел.
  • exclude-path - файлы, путь к которым содержит одно из значений этой опции, не будут проанализированы.
  • disabled-keywords - ключевые слова. Сообщения, указывающие на строки, содержащие эти ключевые слова, будут исключены из обработки.

Имя опции отделяется от значений символом '='. Каждая опция указывается на отдельной строке. Комментарии пишутся на отдельных строках, перед комментарием ставится символ #.

Добавление своих форматов вывода

Для добавления своего формата вывода следует выполнить следующие действия:

Создать свой класс вывода, сделав его наследником от класса IOutput, и переопределить виртуальный метод void write(const AnalyzerMessage& msg). В этом методе описать вывод сообщения в нужном формате. Поля структуры AnalyzerMessage указаны в файле analyzermessage.h. Сделать по аналогии с уже существующими классами вывода (например, XMLOutput).

В OutputFactory::OutputFactory в m_outputs добавить свой формат по аналогии с уже указанными там. Как вариант, добавить его через метод OutputFactory::registerOutput.

После этих действий формат будет доступен как значение опции -t утилиты.

Рассылка результатов анализа (утилита blame-notifier)

Утилита blame-notifier предназначена для автоматизации процесса оповещения разработчиков, заложивших в репозиторий код, на который анализатор PVS-Studio выдал предупреждения. Отчет анализатора подается на вход blame-notifier с указанием дополнительных параметров; утилита находит файлы, в которых были обнаружены предупреждения и формирует HTML-отчет на каждого "виновного" разработчика. Также возможен вариант рассылки полного отчета: внутри него будут содержаться все предупреждения, относящиеся к каждому "виновному" разработчику.

Способы установки и использования утилиты описаны в соответствующем разделе документации: "Оповещение команд разработчиков (утилита blame-notifier)".

Массовое подавление сообщений анализатора

Массовое подавление предупреждений позволяет легко внедрить анализатор в любой проект и сразу начать получать выгоду от этого, т.е. находить новые ошибки. Этот механизм позволяет запланировать исправление пропущенных предупреждений в будущем, не отвлекая разработчиков от выполнения текущих задач.

Есть несколько способов использования этого механизма, в зависимости от варианта интеграции анализатора.

Анализ с помощью утилиты pvs-studio-analyzer

Для подавления всех предупреждений анализатора (первый раз и в последующих случаях) необходимо выполнять команду:

pvs-studio-analyzer suppress /path/to/report.log

Если вы хотите подавить предупреждение для какого-либо конкретного файла, воспользуйтесь флагом --file(-f):

pvs-studio-analyzer suppress -f test.c /path/to/report.log

Помимо самого файла, вы можете явно указать номер строки для подавления:

pvs-studio-analyzer suppress -f test.c:22 /path/to/report.log

При такой записи будут подавлены все предупреждения, которые находятся на строке 22 файла 'test.c'.

Этот флаг можно указывать несколько раз, тем самым подавив предупреждения сразу в нескольких файлах.

Помимо явного указания файла, есть механизм подавления конкретных диагностик:

pvs-studio-analyzer suppress -v512 /path/to/report.log

Флаг --warning(-v) так же можно указывать несколько раз:

pvs-studio-analyzer suppress -v1040 -v512 /path/to/report.log

Указанные выше флаги --file и --warning можно комбинировать для более точечного подавления предупреждений:

pvs-studio-analyzer suppress -f test.c:22 -v512 /path/to/report.log

Так, указанная выше команда подавит все предупреждения диагностики V512 на 22 строке файла 'test.c'.

Анализ проекта можно запускать как прежде. При этом подавленные предупреждения будут фильтроваться:

pvs-studio-analyzer analyze ... -s /path/to/suppress.json \
                                -o /path/to/report.log
plog-converter ...

Прямая интеграция анализатора в сборочную систему

Прямая интеграция анализатора может выглядеть следующим образом:

.cpp.o:
  $(CXX) $(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@
  $(CXX) $(CFLAGS) $< $(DFLAGS) $(INCLUDES) -E -o $@.PVS-Studio.i
  pvs-studio --cfg $(PVS_CFG) --source-file $< --i-file $@.PVS-Studio.i
    --output-file $@.PVS-Studio.log

В этом режиме анализатор не может одновременно проверять исходные файлы и фильтровать их. Поэтому для фильтрации и подавления предупреждений потребуются дополнительные команды.

Для подавления всех предупреждений анализатора также необходимо выполнять команду:

pvs-studio-analyzer suppress /path/to/report.log

Для фильтрации нового лога необходимо воспользоваться следующими командами:

pvs-studio-analyzer filter-suppressed /path/to/report.log
plog-converter ...

Файл с подавленными предупреждениями также имеет имя по умолчанию suppress_base.json, для которого при необходимости можно задать произвольное имя.

Описание распространённых проблем и их решение

1. Утилита strace выдаёт сообщение вида:

strace: invalid option -- 'y'

Вам необходимо обновить версию программы strace. Анализ проекта без интеграции в сборочную систему - сложная задача, а с этой опцией анализатору удаётся получить важную информацию о компиляции проекта.

2. Утилита strace выдаёт сообщение вида:

strace: umovestr: short read (512 < 2049) @0x7ffe...: Bad address

Такие ошибки возникают в системных процессах и на сборку/анализ проекта не влияют.

3. Утилита pvs-studio-analyzer выдаёт сообщение вида:

No compilation units found

Анализатору не удалось обнаружить файлы для анализа. Возможно, вы используете кросс-компиляторы для сборки проекта. Смотрите раздел "Если вы используете кросс-компиляторы" в этой документации.

4. Отчёт анализатора состоит из подобных строк:

r-vUVbw<6y|D3 h22y|D3xJGy|D3pzp(=a'(ah9f(ah9fJ}*wJ}*}x(->'2h_u(ah

Анализатор сохраняет отчёт в промежуточном формате. Для просмотра отчёта его необходимо преобразовать в читабельный формат с помощью утилиты plog-converter, которая устанавливается вместе с анализатором.

5. Анализатор выдаёт ошибку:

Incorrect parameter syntax:
The ... parameter does not support multiple instances.

При вызове анализатора какой-то из параметров задали несколько раз.

Такое может возникнуть, если часть параметров анализатора определили в конфигурационном файле, а часть передали через параметры командной строки. При этом случайно определив какой-нибудь параметр несколько раз.

При использовании утилиты pvs-studio-analyzer почти все параметры определяются автоматически, поэтому она может работать без конфигурационного файла. Дублирование таких параметров тоже может приводить к такой ошибке.

6. Анализатор выдаёт предупреждение:

V001 A code fragment from 'path/to/file' cannot be analyzed.

Если анализатору не удаётся понять какой-нибудь фрагмент кода, то он его пропускает и выдаёт предупреждение V001. На анализ других фрагментов кода такая ситуация обычно не влияет, но если такой код находится в заголовочном файле, то таких предупреждений может быть очень много. Для поддержки проблемной конструкции пришлите нам препроцессированный файл (.i) для проблемного файла с исходным кодом.

Заключение

Если у вас возникли вопросы или проблемы с запуском анализатора, то напишите нам.

Запуск PVS-Studio в Docker

Docker — программное обеспечение для автоматизации развёртывания и управления приложениями в средах с поддержкой контейнеризации. Позволяет "упаковать" приложение со всем его окружением и зависимостями в контейнер, который может быть перенесён на любую систему, где установлен Docker.

Docker-образы с Linux для C и C++ проектов

Подготовка образа

Для сборки готового образа с последней версией анализатора PVS-Studio можно использовать Dockerfile.

Для debian-based систем:

FROM gcc:7

# INSTALL DEPENDENCIES
RUN apt update -yq \
 && apt install -yq --no-install-recommends wget \
 && apt clean -yq

# INSTALL PVS-Studio
RUN wget -q -O - https://files.viva64.com/etc/pubkey.txt | apt-key add - \
 && wget -O /etc/apt/sources.list.d/viva64.list \
    https://files.viva64.com/etc/viva64.list \
 && apt update -yq \
 && apt install -yq pvs-studio strace \
 && pvs-studio --version \
 && apt clean -yq

Для zypper-based систем:

FROM opensuse:42.3

# INSTALL DEPENDENCIES
RUN zypper update -y \
 && zypper install -y --no-recommends wget \
 && zypper clean --all

# INSTALL PVS-Studio
RUN wget -q -O /tmp/viva64.key https://files.viva64.com/etc/pubkey.txt \
 && rpm --import /tmp/viva64.key \
 && zypper ar -f https://files.viva64.com/rpm viva64 \
 && zypper update -y \
 && zypper install -y --no-recommends pvs-studio strace \
 && pvs-studio --version \
 && zypper clean -all

Для yum-based систем:

FROM centos:7

# INSTALL DEPENDENCIES
RUN yum update -y -q \
 && yum install -y -q wget \
 && yum clean all -y -q

# INSTALL PVS-Studio
RUN wget -q -O /etc/yum.repos.d/viva64.repo \
 https://files.viva64.com/etc/viva64.repo \
 && yum install -y -q pvs-studio strace \
 && pvs-studio --version \
 && yum clean all -y -q

Примечание. PVS-Studio для Linux также может быть скачан по следующим постоянным ссылкам:

https://files.viva64.com/pvs-studio-latest.deb

https://files.viva64.com/pvs-studio-latest.tgz

https://files.viva64.com/pvs-studio-latest.rpm

Команда для сборки образа:

docker build -t viva64/pvs-studio:7.09 -f Dockerfile

Примечание. Базовый образ и зависимости необходимо изменить для целевого проекта.

Запуск контейнера

Запустить анализ, например, CMake-проекта можно с помощью следующей команды:

docker run --rm -v "~/Project":"/mnt/Project" \
           -w "/mnt/Project" viva64/pvs-studio:7.09 \
           sh -c 'mkdir build && cd build &&
                  cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On .. && make -j8 &&
                  pvs-studio-analyzer analyze ... -o report.log -j8 ...'

При этом конвертер отчётов анализатора (plog-converter) рекомендуется запускать вне контейнера, чтобы отчёты содержали корректные пути до исходных файлов. Единственный тип отчёта, который имеет смысл сгенерировать в контейнере, это fullhtml, (HTML отчёт с сортировкой предупреждений и навигацией по коду). Для получения других типов отчёта требуется дополнительная настройка анализатора.

При проверке не CMake-проектов в контейнере в режиме трассировки вызовов компилятора может возникнуть такая ошибка:

strace: ptrace(PTRACE_TRACEME, ...): Operation not permitted
Error: Command strace returned 1 code.

Для исправления ошибки необходимо запустить докер с дополнительными правами:

docker run ... --security-opt seccomp:unconfined ...

или так:

docker run ... --cap-add SYS_PTRACE ...

Настройка анализатора

Указание лицензии анализатора

Т.к. время жизни контейнера ограничено, файл лицензии анализатора необходимо закоммитить в образ, либо указывать анализатору через смонтированный каталог:

pvs-studio-analyzer analyze ... -l /path/to/PVS-Studio.lic ...

Восстановление путей к исходникам в отчёте

Чтобы получить отчёт анализатора с корректными путями до файлов с исходным кодом, анализатору предварительно необходимо указать директорию проекта:

pvs-studio-analyzer analyze ... -r /path/to/project/in/container ...

После чего запустить конвертер отчёта вне контейнера.

На Linux или macOS:

plog-converter ... -r /path/to/project/on/host ...

на Windows:

PlogConverter.exe ... -r /path/to/project/on/host

Также в Windows можно открыть отчёт без конвертации в утилите Compiler Monitoring UI.

Исключение директорий из анализа

Исключить из анализа директории со сторонними библиотеками, тестами и директорию компилятора можно с помощью параметра -e:

pvs-studio-analyzer analyze ... -e /path/to/tests ... -e /path/to/contrib ...

Настройка кросс-компилятора

Если контейнер содержит кросс-компилятор или компилятор без алиасов (например, g++-7), то имя компилятора надо указать дополнительно:

pvs-studio-analyzer analyze ... -C g++-7 -C compilerName ...

Docker-образы с Linux для Java проектов

Подготовка образа

Вариант установки из архива

FROM openkbs/ubuntu-bionic-jdk-mvn-py3

ARG PVS_STUDIO_CORE="7.09.41421"

RUN wget "https://files.viva64.com/java/pvsstudio-cores/${PVS_STUDIO_CORE}.zip"\
-O ${PVS_STUDIO_CORE}.zip \
 && mkdir -p ~/.config/PVS-Studio-Java \
 && unzip ${PVS_STUDIO_CORE}.zip -d ~/.config/PVS-Studio-Java \
 && rm -rf ${PVS_STUDIO_CORE}.zip

Команда для сборки образа:

docker build -t viva64/pvs-studio:7.09 -f Dockerfile

Вариант коммита слоя с анализатором

Анализатор выкачивается автоматически при первом анализе проекта. Можно предварительно задать имя контейнера и выполнить анализ проекта:

docker run --name analyzer
  -v "D:\Project":"/mnt/Project"
  openkbs/ubuntu-bionic-jdk-mvn-py3
  sh -c "cd /mnt/Project && mvn package
    && mvn pvsstudio:pvsAnalyze -Dpvsstudio.licensePath=/path/to/PVS-Studio.lic"

после чего выполнить коммит в новый образ:

docker commit analyzer viva64/pvs-studio:7.09

Примечание. Базовый образ и зависимости необходимо изменить для целевого проекта. Установку и запуск анализатора следует выполнять от имени одного и того же пользователя.

Запуск контейнера

Регулярно запускать анализ проекта следует аналогичным образом, добавив параметр --rm:

docker run --rm -v "D:\Project":"/mnt/Project"
  openkbs/ubuntu-bionic-jdk-mvn-py3
  sh -c "cd /mnt/Project
    && mvn package
    && mvn pvsstudio:pvsAnalyze -Dpvsstudio.licensePath=/path/to/PVS-Studio.lic"

Настройка анализатора

Вся настройка анализатора производится в проектом файле Maven или Gradle, в который интегрирован анализ.

Docker-образы с Windows для C, C++ и C# проектов

Данный раздел документации находится в разработке.

Docker-образы с Windows для Java проектов

Данный раздел документации находится в разработке.

Дополнительные ссылки

Запуск PVS-Studio в Jenkins

Автоматизирование запуска анализатора

Для автоматизации процедуры анализа в CI (Continuous Integration) необходимо запускать анализатор как консольное приложение.

В Jenkins Вы можете создать один из следующих шагов сборки:

  • Execute Windows batch command
  • Windows PowerShell
  • Execute shell

и вписать команду анализа (и команду конвертации отчёта в нужный формат).

Примеры команд запуска анализатора и интеграции в сборочные системы приведены на следующих страницах документации:

Плагин для визуализации результатов анализа

На странице загрузки скачайте PVS-Studio Plugin в разделе про Jenkins. На диск сохранится файл pvs-studio.hpi. В таких пакетах распространяются Jenkins-плагины для ручной установки.

Установить плагин можно через UI, перейдя в меню Manage Jenkins > Manage Plugin > Advanced > Upload Plugin > Choose File, или через Jenkins CLI:

java -jar jenkins-cli.jar -s http://localhost:8080/ install-plugin SOURCE ...

PVS-Studio Plugin позволяет публиковать результаты статического анализа, для чего он использует отчёт анализатора в виде .html файла, который формируется следующими способами.

Windows: C, C++, C#

PlogConverter.exe ... --renderTypes Html ...

Linux/macOS: C, C++

plog-converter ... --renderTypes html ...

Windows/Linux/macOS: Java

В настройках плагинов для Maven и Gradle в поле outputType указать значение html.

Для публикации результатов анализа в настройках проекта необходимо добавить послесборочный шаг (секция Post-build Actions) Publish PVS-Studio analysis result. Обязательное поле - Path to PVS-Studio analysis report, в котором задаётся путь до .html-файла, содержимое которого и будет отображаться на странице сборки. Поддерживаются относительные (относительно workspace'a проекта) пути. Также поддерживаются переменные окружения Jenkins.

Если необходимо отобразить объединённые результаты из нескольких отчётов анализатора, то их можно объединить с помощью описанных выше утилит для конвертации. Аналогичным способом возможна дополнительная фильтрация результатов анализа.

После успешного выполнения шага публикации результатов анализа PVS-Studio, они будут отображены на страницах сборки. Результаты сохраняются для каждой сборки, что позволит просматривать отчёт анализатора, соответствующий каждой конкретной сборке.

В случае, если результирующий отчёт анализатора имеет большой объём, на странице сборки будет отображаться его превью, а полный отчёт будет доступен для просмотра при нажатии ссылок View full report над / под превью отчёта, или Full PVS-Studio analysis report в меню слева.

Внешний вид страницы сборки с отображением результатов анализа PVS-Studio:

https://import.viva64.com/docx/manual/Jenkins_ru/image1.png

Warnings Next Generation Plugin

Warnings NG Plugin поддерживает отчёты анализатора PVS-Studio, начиная с версии плагина 6.0.0. Этот плагин предназначен для визуализации результатов работы различных анализаторов.

Установить плагин можно из стандартного репозитория Jenkins в меню Manage Jenkins > Manage Plugins > Available > Warnings Next Generation Plugin:

https://import.viva64.com/docx/manual/Jenkins_ru/image3.png

Для публикации результатов анализа в настройках проекта необходимо добавить послесборочный шаг (секция Post-build Actions) Record compiler warnings and static analysis results. Далее необходимо раскрыть список Tool и выбрать PVS-Studio. В поле Report File Pattern можно указать маску или путь к отчёту анализатора. Поддерживаются отчёты с расширением .plog и .xml.

В поле Report Encoding указывается кодировка, в которой будет считан файл отчета. Если поле пустое, то будет использована кодировка операционной системы, в которой запущен Jenkins. Поля Custom ID и Custom Name переопределяют отображаемые в интерфейсе идентификатор и имя выбранной утилиты соответственно.

Сгенерировать отчёт в нужном формате можно следующими способами.

Windows: C, C++, C#

Отчёты с расширением .plog являются стандартными для Windows.

Linux/macOS: C, C++

plog-converter ... --renderTypes xml ...

Windows/Linux/macOS: Java

В настройках плагинов для Maven и Gradle в поле outputType указать значение xml.

После сборки проекта слева в списке появится новый элемент меню PVS-Studio Warnings. По нажатию на него открывается страница, где представлена визуализация данных отчета, созданного анализатором PVS-Studio:

https://import.viva64.com/docx/manual/Jenkins_ru/image4.png

Также при нажатии на значение в столбце File в браузере будет открыт файл с исходным кодом на строчке, где была найдена ошибка. Если открытие файла не работает, значит отчет был сформирован вне сборочной директории или файлы, участвовавшие в составлении отчета, перемещены или удалены.

https://import.viva64.com/docx/manual/Jenkins_ru/image6.png

В других CI настройка запуска анализатора и работа с отчётом выполняются аналогичным образом.

Дополнительные ссылки

Запуск PVS-Studio в TeamCity

Автоматизирование запуска анализатора

Для автоматизации процесса анализа в CI (Continuous Integration) необходимо запускать анализатор как консольное приложение.

В TeamCity необходимо создать Build Step со следующими параметрами:

  • Runner type: Command Line;
  • Step Name: <name>;
  • Run: Custom script;
  • Custom script: <script>.

В скрипте напишите команду анализа (и команду конвертации отчёта в нужный формат).

Примеры команд для запуска анализатора, обработки результатов анализа и интеграции в сборочные системы приведены на следующих страницах документации:

Просмотр результатов анализа

Первый способ

В TeamCity можно прикреплять отчёты анализатора в формате HTML к сборкам, указав их в артефактах.

Сгенерировать HTML-отчёт с навигацией по коду можно следующими способами:

Windows: C, C++, C#

PlogConverter.exe ... --renderTypes FullHtml ...

Linux/macOS: C, C++

plog-converter ... --renderTypes fullhtml ...

Windows/Linux/macOS: Java

В настройках плагинов для Maven и Gradle в поле 'outputType' указать значение 'fullhtml'.

В меню Edit Configuration Settings > General Settings > Artifact paths укажите каталог с HTML-отчётом.

После успешного выполнения сборки отчёт анализатора формате html будет доступен в артефактах. Чтобы открыть его, нужно кликнуть на файл index.html на вкладке 'Artifacts'. Также можно сделать так, чтобы отчёт анализатора отображался на специальной вкладке отчёта о сеансе сборки. Для этого необходимо перейти в настройки проекта, открыть 'Report Tabs' и добавить новую вкладку отчёта сборки ('Create new build report tab').

В окне добавления вкладки в поле 'Start page' необходимо указать путь к файлу index.html относительно корневой папки артефактов. Например, если содержимое вкладки 'Artifacts' выглядит примерно так:

https://import.viva64.com/docx/manual/TeamCity_ru/image1.png

То в поле 'Start Page' нужно записать путь 'fullhtml/index.html'. После добавления вкладки результаты анализа можно будет просматривать на ней:

https://import.viva64.com/docx/manual/TeamCity_ru/image2.png

При переходе к предупреждениям анализатора будет открываться дополнительная вкладка браузера:

https://import.viva64.com/docx/manual/TeamCity_ru/image4.png

В других CI настройка запуска анализатора и работа с отчётом выполняются аналогичным образом.

Второй способ

Конвертер поддерживает стандартные отчёты для TeamCity - TeamCity Inspections Type. После генерации отчёта его необходимо вывести в stdout на любом шаге сборки.

Сгенерировать такой отчёт и вывести его в stdout можно следующими способами:

Windows: C, C++, C#

PlogConverter.exe ... –-renderTypes=TeamCity -o TCLogsDir ...
Type TCLogsDir\MyProject.plog_TeamCity.txt

Linux/macOS: C, C++

plog-converter ... -t teamcity -o report_tc.txt ...
cat report_tc.txt

Windows/Linux/macOS: Java

Поддержка скоро появится.

После успешного выполнения сборки отчёт анализатора появится на новой вкладке в информации об этой сборке:

https://import.viva64.com/docx/manual/TeamCity_ru/image6.png

Навигацию по коду можно осуществить при помощи нажатия на номер строки слева от диагностического правила. Переход осуществится при условии наличия абсолютного пути к исходному файлу, открытого проекта в IDE (Eclipse, Visual Studio, IntelliJ IDEA) и установленного плагина TeamCity.

Дополнительные ссылки

Оповещение команд разработчиков (утилита blame-notifier)

Утилита blame-notifier предназначена для автоматизации процесса оповещения разработчиков, заложивших в репозиторий код, на который анализатор PVS-Studio выдал предупреждения. Отчет анализатора подается на вход blame-notifier с указанием дополнительных параметров; утилита находит файлы, в которых были обнаружены предупреждения и формирует HTML-отчет на каждого "виновного" разработчика. Также возможен вариант рассылки полного отчета: внутри него будут содержаться все предупреждения, относящиеся к каждому "виновному" разработчику.

Утилита blame-notifier доступна только при наличии Enterprise лицензии. Для получения лицензии, пожалуйста, напишите нам.

Примечание. Название утилиты различается под разными платформами. Под Windows она имеет название BlameNotifier.exe, под Linux и macOS - blame-notifier. Если речь не идёт про утилиту под конкретную ОС, во избежание дублирования в данном документе используется название blame-notifier.

Для работы утилиты blame-notifier под Linux и macOS требуется .NET Core Runtime 3.1.

Установка

На Windows

Утилиту BlameNotifier можно найти в установочной директории PVS-Studio (по умолчанию это путь "C:\Program Files (x86)\PVS-Studio\").

На Linux

Установка из репозиториев

Для debian-based систем:

wget -q -O - https://files.viva64.com/etc/pubkey.txt | \
  sudo apt-key add -
sudo wget -O /etc/apt/sources.list.d/viva64.list \
  https://files.viva64.com/etc/viva64.list
sudo apt-get update
sudo apt-get install blame-notifier

Для yum-based систем:

wget -O /etc/yum.repos.d/viva64.repo \
  https://files.viva64.com/etc/viva64.repo
yum update
yum install blame-notifier

Для zypper-based систем:

wget -q -O /tmp/viva64.key https://files.viva64.com/etc/pubkey.txt
sudo rpm --import /tmp/viva64.key
sudo zypper ar -f https://files.viva64.com/rpm viva64
sudo zypper update
sudo zypper install blame-notifier

Прямые ссылки для загрузки

blame-notifier.deb

blame-notifier.rpm

blame-notifier.tar.gz

На macOS

Установка из Homebrew

Установка:

brew install viva64/pvs-studio/blame-notifier

Обновление:

brew upgrade blame-notifier

Прямые ссылки для загрузки

blame-notifier-macos.tar.gz

Использование

Флаг "--help" выводит основную информацию об утилите:

blame-notifier --help

Пример использования утилиты blame-notifier (одной строкой):

blame-notifier path/to/PVS-Studio.log 
--VCS Git 
--recipientsList recipients.txt 
--server ... --sender ... --login ... --password ...

Параметры утилиты

Ниже приводится краткое описание параметров утилиты:

  • --VCS (или -v): обязательный параметр: тип системы контроля версий, с которой будет работать утилита. Поддерживаемые системы: Git, Svn, Mercurial, Perforce.
  • --recipientsList (или -r): путь до текстового файла, содержащего список получателей отчетов. Формат файла описывается ниже.
  • --srcRoot (или -t): задаёт замену для специального "SourceTreeRoot" маркера. Если лог анализатора был сгенерирован с этим маркером, данный параметр необходим для восстановления путей до файлов.
  • --analyzer (или -a): производит фильтрацию предупреждений согласно маске. Более подробно маски фильтрации описываются ниже.
  • --excludedCodes (или -e): задает список предупреждений (через ","), которые не следует включать в результирующий отчет.
  • --settings (или -c): задает путь к файлу настроек PVS-Studio. Данный флаг актуален только при работе под Windows. BlameNotifier прочитает настройки отключенных предупреждений из переданного файла настроек. По сути, этот параметр расширяет список отключаемых предупреждений параметра "--excludedCodes".
  • --server (или -x): обязательный параметр: SMTP-сервер для отправки отчетов.
  • --sender (или -s): обязательный параметр: email адрес отправителя писем.
  • --login (или -l): обязательный параметр: имя пользователя для авторизации.
  • --password (или -w): пароль пользователя для авторизации.
  • --port (или -p): номер порта для отправления писем. По умолчанию указан порт N25.
  • --maxTasks (или -m): максимальное число параллельно запущенных blame-процессов. По умолчанию, или если задано отрицательное число, blame-notifier будет использовать 2 * N процессов (где N - число ядер процессора).
  • --progress (или -g): включить или отключить логирование. По умолчанию логирование выключено.
  • --enableSSL: включить использование протокола SSL. По умолчанию выключено;
  • --vcsBasedRecipientsList: использовать данные из СКВ для составления списка получателей отчётов. Поддерживаемые СКВ: Perforce. По умолчанию опция выключена.

При использовании утилиты должен быть указан как минимум один из флагов, через который задаётся список получателей отчётов: '--recipientsList' или '--vcsBasedRecipientsList'. При необходимости эти флаги могут использоваться совместно.

Формат файла получателей отчёта

Формат файла со списком получателей отчётов:

# Получатели полного отчёта
username_1 *email_1
...
username_N *email_N
# Получатели собственных ошибок
username_1 email_1
...
username_N email_N

Закомментировать строку можно символом "#". Для получателей полных отчетов необходимо добавить символ "*" в начале или в конце email адреса. Полный отчет будет включать все предупреждения, отсортированные по разработчикам.

Формат масок фильтрации

Маски фильтрации имеют следующим вид: MessageType:MessageLevels.

MessageType может принимать одно из следующих значений: GA, OP, 64, CS, MISRA, Fail.

MessageLevels может принимать значение от 1 до 3.

Возможна комбинация разных масок через ";" (без пробелов), например:

--analyzer=GA:1,2;64:1

В таком случае будут обработаны предупреждения общего назначения (GA) уровней 1 и 2 и 64-битные предупреждения (64) уровня 1.

PVS-Studio и Continuous Integration

В данной статье рассматривается встраивание PVS-Studio в процесс непрерывной интеграции в среде Windows. Встраивание в процесс CI в среде Linux описано в статье "Как запустить PVS-Studio в Linux".

Наиболее эффективный сценарий использования статического анализа

Прежде чем перейти к основной теме данной статьи, стоит отметить, что использование PVS-Studio исключительно на сборочном сервере эффективно, но не оптимально. Лучшим вариантом будет построение двухуровневой системы проверки исходного кода - локально на машинах разработчиков и на сборочном сервере.

Этот принцип происходит из того факта, что чем раньше обнаружена ошибка, тем меньше стоимость и сложность её исправления. Поэтому необходимо стремиться к как можно более раннему обнаружению и исправлению ошибок, для чего и необходимо использование PVS-Studio на машинах разработчиков. Рекомендуется использование режима инкрементального анализа, позволяющего автоматически запускать проверку только изменённого кода после сборки проекта.

Тем не менее использование PVS-Studio на машинах разработчиков не исключает возможности попадания ошибок в систему контроля версий. Для отслеживания таких ситуаций и нужно иметь второй уровень защиты - регулярный запуск статического анализатора на сборочном сервере. Даже в случае попадания ошибки в систему контроля версий, её удастся своевременно выявить и исправить. Встраивание анализа в процесс ночных сборок позволит на следующий день получать информацию обо всех ошибках, допущенных в течение прошлого дня, и оперативно поправить проблемный код.

Примечание. Не рекомендуется конфигурировать статический анализ кода на сервере таким образом, чтобы он запускался на каждый коммит, так как анализ может занимать продолжительное время. Если необходим именно такой сценарий использования и при этом сборочной системой проекта является MSBuild, можно воспользоваться режимом инкрементального анализа command line модуля 'PVS-Studio_Cmd.exe'. За дополнительной информацией обратитесь к разделу "Инкрементальный анализ в command line модуле 'PVS-Studio_Cmd.exe'" текущего документа. Также для анализа файлов при инкрементальной сборке (вне зависимости от сборочной системы) можно использовать утилиту 'CLMonitor.exe' (только для анализа C, C++ кода). Более подробно использование утилиты 'CLMonitor.exe' описано в разделе "Система мониторинга компиляции" текущего документа.

Подготовка к непрерывной интеграции

Подготовка к встраиванию PVS-Studio в процесс непрерывной интеграции - важный этап, позволяющий сэкономить время в дальнейшем и использовать статический анализатор более эффективно. В этом разделе будут рассмотрены те особенности настройки PVS-Studio, которые упростят последующую работу.

Автоматическое развёртывание PVS-Studio

Для установки PVS-Studio требуются права администратора. Автоматическая установка осуществляется следующей командой, выполненной в командной строке (одной строкой):

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/norestart /nocloseapplications

Выполнение этой команды приведёт к установке всех доступных компонентов PVS-Studio. Обратите внимание, что PVS-Studio может потребоваться перезагрузка компьютера в случае, например, если обновляемые файлы были заблокированы. Если установщик запустить без флага 'NORESTART', перезагрузка может произойти без предварительных уведомлений или диалогов.

В состав дистрибутива входит утилита 'PVS-Studio-Updater.exe', позволяющая проверять наличие обновлений анализатора, а в случае их наличия, загрузить и установить их на локальной машине. Для запуска утилиты в 'silent' режиме следует использовать те же параметры, что и для установки дистрибутива:

PVS-Studio-Updater.exe /verysilent /suppressmsgboxes

Файл настроек генерируется автоматически при запуске Visual Studio с установленным плагином PVS-Studio или приложением C and C++ Compiler Monitoring UI (Standalone.exe), и в дальнейшем он может быть отредактирован или скопирован на другие машины. Информация о лицензии также хранится в файле настроек. Расположение файла по умолчанию:

%AppData%\PVS-Studio\Settings.xml

Для более детальной информации по автоматическому развёртыванию PVS-Studio обратитесь к статье "Автоматическое развёртывание PVS-Studio".

Предварительная настройка анализатора

Перед использованием анализатора необходимо выполнить его предварительную настройку, что поможет оптимизировать работу со списком предупреждений, а также (возможно) повысить скорость проведения анализа.

Примечание. Описанные ниже опции можно изменить, напрямую отредактировав файл настроек, или воспользовавшись интерфейсом страницы настроек в плагине к Visual Studio или в приложении C and C++ Compiler Monitoring UI.

Часто бывает полезно исключить из анализа определённые файлы или даже целые директории. Это позволит не анализировать код сторонних библиотек, сократив общее время анализа, и оставив в выводе только те предупреждения, которые актуальны именно для вашего проекта. По умолчанию в настройках анализатора уже присутствуют исключения для некоторых файлов или путей, например, для библиотеки boost. Более подробно исключение файлов из анализа описано в статье "Настройки: Don't Check Files".

На этапе внедрения также следует отключить те диагностические правила PVS-Studio, которые неактуальны для проверяемого проекта. Существует возможность отключения как отдельных диагностических правил, так и целых групп. Если вы изначально знаете диагностики, неактуальные для вашего проекта (например, 64-битные ошибки), есть смысл отключить их сразу. Это также может ускорить работу анализатора. Если список таких диагностических правил неизвестен, то при необходимости их можно будет отключить позже. Более подробно отключение диагностических правил описано в статье "Настройки: Detectable Errors".

Отключение предупреждений на старый код

В случае внедрения статического анализа в существующий проект, когда объём кодовой базы уже существенен, проверка исходного кода может выявить большое количество ошибок в существующем коде. Команда разработчиков, занимающихся данным проектом, может не иметь ресурсов, необходимых для исправления всех этих предупреждений. В таком случае возникает необходимость убрать все предупреждения, обнаруженные в старом коде, чтобы с текущего момента видеть только те предупреждения анализатора, которые были выданы на вновь написанный/модифицированный код.

Достичь желаемого результата можно с использованием механизма массового подавления сообщений анализатора. Более подробно про это написано в статье: "Массовое подавление сообщений анализатора".

Примечание 1. Если необходимо скрыть только отдельные предупреждения анализатора, следует воспользоваться механизмом подавления ложных срабатываний, описанном в статье "Подавление ложных предупреждений".

Примечание 2. Используя SonarQube, можно изменять отображение предупреждений, найденных за определённый период времени. Таким образом, можно настроить отображение только тех предупреждений, которые были найдены после внедрения анализатора (т.е. отключить отображение предупреждений на старый код).

Встраивание PVS-Studio в процесс непрерывной интеграции

PVS-Studio достаточно просто встраивается в процесс непрерывной интеграции, а также предоставляет средства для удобной обработки результатов работы анализатора.

Интеграция PVS-Studio с платформой SonarQube доступна только при наличии Enterprise лицензии. Для заказа лицензии, пожалуйста, напишите нам.

Ниже будут описаны принципы анализа проектов, основанных на различных сборочных системах, а также утилиты для работы с результатами анализа.

Анализ исходного кода MSBuild / Visual Studio проектов

В данном разделе будет описан наиболее эффективный вариант анализа MSBuild / Visual Studio проектов, то есть файлов решений Visual Studio (.sln), проектов Visual C++ (.vcxproj) и Visual C# (.csproj).

Основные сведения

Анализ из командной строки проектов, перечисленных выше, производится за счёт использования модуля 'PVS-Studio_Cmd.exe', находящегося в установочной директории PVS-Studio. Расположение установочной директории по умолчанию - 'C:\Program Files (x86)\PVS-Studio\'.

Передавая модулю 'PVS-Studio_Cmd.exe' различные аргументы, можно регулировать параметры анализа. Увидеть список всех доступных аргументов можно, выполнив команду:

PVS-Studio_Cmd.exe --help

Анализатор имеет один обязательный аргумент - '--target', с помощью которого задаётся объект для проверки (.sln, .vcxproj или .csproj файл). Остальные аргументы являются опциональными и подробно описываются в статье "Проверка Visual C++ (.vcxproj) и Visual C# (.csproj) проектов из командной строки с помощью PVS-Studio".

Рассмотрим пример запуска анализа на .sln файле (одной строкой):

PVS-Studio_Cmd.exe --target "targetsolution.sln" --platform "Any CPU" 
--output "results.plog" --configuration "Release"

Исполнение этой команды запустит анализ .sln файла 'targetsolution.sln' для платформы 'Any CPU' и конфигурации 'Release'. Выходной файл ('results.plog') будет создан в директории проверяемого проекта. При анализе будут использоваться стандартные настройки анализатора, так как явно не указано обратное.

Модуль 'PVS-Studio_Cmd.exe' имеет ряд ненулевых кодов возврата, посредством которых информирует о результирующем состоянии анализа. Код возврата представляет собой битовую маску, маскирующую все возможные состояния, возникшие во время работы утилиты. То есть ненулевой код не является свидетельством того, что утилита закончила свою работу некорректно. Подробное описание кодов возврата приведено в упомянутой выше статье "Проверка Visual C++ (.vcxproj) и Visual C# (.csproj) проектов из командной строки с помощью PVS-Studio".

Получение результатов анализа только нового / модифицированного кода

При регулярном запуске анализатора может возникнуть необходимость в получении отчёта анализатора, содержащего предупреждения, выданные только на вновь написанный / модифицированный код. При ночном анализе на сборочном сервере это позволит видеть только те предупреждения, которые были допущены в течение предыдущего дня.

В случае необходимости получения такого результата при запуске модуля 'PVS-Studio_Cmd.exe' необходимо указывать аргумент командной строки '--suppressAll'. При наличии этого флага все сообщения будут добавлены в базу подавленных сообщений (.suppress файлы соответствующих проектов) после сохранения результатов проверки. Следовательно, при следующей проверке эти сообщения выданы не будут. Если всё же потребуется посмотреть старые сообщения, рядом с .plog файлом, содержащим новые сообщения, будет сохранён полный лог проверки.

Механизм массового подавления предупреждений анализатора более подробно описан в статье "Массовое подавление сообщений анализатора".

Примечание. При использовании платформы SonarQube можно наблюдать только за новыми предупреждениями, не используя механизмы подавления. Для этого необходимо настроить отображение результатов анализа таким образом, чтобы видеть изменения только за последний день.

Инкрементальный анализ в command line модуле 'PVS-Studio_Cmd.exe'

Режим инкрементального анализа в PVS-Studio позволяет проверять только файлы, изменённые/затронутые с момента последней сборки проекта. Этот режим доступен как при работе с использованием плагина для Visual Studio, так и при проверке проектов с использованием command line модуля PVS-Studio. Использование режима инкрементального анализа позволит получить предупреждения только на модифицированный код, а также сократить время анализа, так как те части проекта, которые не изменялись, проанализированы не будут.

Данный режим актуален, если система непрерывной интеграции настроена на автоматическую инкрементальную сборку после обнаружения изменений в системе контроля версий, то есть, если сборка и анализ проекта на сервере происходит неоднократно в течение дня.

Использование инкрементального анализа в модуле 'PVS-Studio_Cmd.exe' регулируется с помощью флага '--incremental'. Доступны следующие режимы работы:

  • Scan - проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ. Непосредственно анализ выполнен не будет.
  • Analyze - выполнить инкрементальный анализ. Этот шаг должен выполняться после выполнения шага Scan, и может выполняться как до, так и после сборки решения или проекта. Статический анализ будет выполнен только для измененных файлов с момента последней сборки.
  • ScanAndAnalyze - проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ, и сразу же выполнить инкрементальный анализ измененных файлов с исходным кодом.

Для получения подробной информации об инкрементальном анализе в PVS-Studio обратитесь к статье "Режим инкрементального анализа PVS-Studio".

Примечание. При использовании режима инкрементального анализа следует учитывать некоторые особенности. Если PVS-Studio использует препроцессор Visual C++ ('cl.exe'), возможно возникновение ситуации с блокировкой файлов. Это связано с тем, что при попытке записи файла, он может быть заблокирован компилятором 'cl.exe', выполняющим препроцессирование. При использовании препроцессора Clang данная ситуация возникает значительно реже. Это следует учитывать при решении конфигурирования сервера в пользу инкрементального анализа вместо полноценного анализа по ночам.

Анализ CMake проектов

Если стоит задача анализа CMake проектов, рекомендуется генерировать из них решения для среды Visual Studio и в дальнейшем работать с ними. Это позволит полноценно использовать модуль 'PVS-Studio_Cmd.exe' и все связанные с этим фактом преимущества.

Анализ исходного кода проектов со специфичными сборочными системами

В случае, если проект не использует сборочную систему MSBuild, его не получится проанализировать с использованием command line модуля 'PVS-Studio_Cmd.exe'. Тем не менее, в состав дистрибутива входят утилиты, с помощью которых можно проверить даже проекты со специфичными сборочными системами.

Система мониторинга компиляции

Система мониторинга компиляции (PVS-Studio Compiler Monitoring, CLMonitoring) предназначена для 'бесшовной' интеграции статического анализа PVS-Studio в любую сборочную систему на ОС семейства Windows, использующую для компиляции файлов один из препроцессоров, поддерживаемых command line анализатором 'PVS-Studio.exe'.

Принцип работы сервера мониторинга (CLMonitor.exe) основан на отслеживании запуска процессов, соответствующих целевому компилятору, и сборе информации об окружении этих процессов. Сервер мониторинга отслеживает запуски процессов только для того пользователя, из-под которого он сам запущен.

Поддерживаемые компиляторы:

  • компиляторы семейства Microsoft Visual C++ (cl.exe);
  • C/C++ компиляторы из GNU Compiler Collection (gcc.exe, g++.exe);
  • компилятор Clang (clang.exe), а также компиляторы на основе Clang.

При интеграции сервера мониторинга в сборочный процесс первоначально необходимо запустить модуль 'CLMonitor.exe' с аргументом 'monitor':

CLMonitor.exe monitor

Это позволит серверу мониторинга запустить самого себя в режиме отслеживания и завершить работу, а сборочной системе - продолжить выполнять оставшиеся задачи. При этом второй (запущенный из первого) процесс CLMonitor будет оставаться запущенным и производить отслеживание сборки.

После завершения сборки необходимо запустить модуль 'CLMonitor.exe' в режиме клиента для генерации препроцессированных файлов и непосредственного запуска статического анализа:

CLMonitor.exe analyze -l "c:\ptest.plog" -u "c:\ptest.suppress" -s

Рассмотрим эту команду более подробно:

  • analyze - запуск модуля 'CLMonitor.exe' для анализа;
  • -l - полный путь до файла, в который будут записаны результаты статического анализа;
  • -u - путь до базы подавления (suppress файл);
  • -s - дописать в базу подавления все новые сообщения текущей проверки.

Более подробно использование системы мониторинга компиляции описано в статье "Система мониторинга компиляции в PVS-Studio".

Примечание. Системе мониторинга компиляции присущ ряд недостатков, связанный с естественными ограничениями такого подхода, а именно - невозможность гарантировать на 100% перехват всех запусков компилятора при сборке (например, при сильной загрузке системы). Также следует помнить о том, что если параллельно выполняются несколько сборок, система может отследить запуски компиляторов сторонней сборки.

Прямая интеграция анализатора в системы автоматизированной сборки

Примечание. Прямая интеграция анализатора возможна только для проверки С/С++ кода.

Прямая интеграция анализатора может быть необходима в случаях отсутствия возможности использования command line модуля 'PVS-Studio_Cmd.exe' (проект собирается не с помощью сборочной системы MSBuild) и системы мониторинга компиляции (см. примечание соответствующего раздела).

В таком случае может потребоваться встроить в сборочный процесс прямой вызов анализатора ('PVS-Studio.exe') и передать ему все необходимые для препроцессирования аргументы. То есть анализатор необходимо вызвать для тех же файлов, для которых вызывается компилятор.

Подробное описание прямой интеграции анализатора в системы автоматизированной сборки приведено в статье "Прямая интеграция анализатора в системы автоматизации сборки (C/C++)".

Работа с результатами анализа

Результатом работы анализатора является .plog файл, имеющий формат XML. Этот файл не предназначен для ручной обработки, например, для чтения программистом. Тем не менее, в состав дистрибутива входят специальные утилиты, цель которых - сделать работу с .plog файлом максимально удобной.

Предварительная фильтрация результатов анализа

Отчёт анализатора можно отфильтровать ещё перед запуском анализа с помощью настройки No Noise. При работе на большой кодовой базе, анализатор неизбежно генерирует большое количество предупреждений. При этом, часто нет возможности поправить все предупреждения сразу. Для того, чтобы иметь возможность сконцентрироваться на правке наиболее важных предупреждений, можно сделать анализ менее "шумным" с помощью данной настройки. Она позволяет полностью отключить генерацию предупреждений низкого уровня достоверности (Low Certainty, 3-ий уровень предупреждений). После перезапуска анализа, сообщения этого уровня полностью пропадут из вывода анализатора.

Когда обстоятельства позволят и более существенные предупреждения анализатора будут исправлены, можно выключить режим No Noise - при следующем анализе все пропавшие ранее предупреждения станут вновь доступны.

Для включения этой настройки используйте окно Specific Analyzer Settings.

PlogConverter

Для преобразования результатов работы анализатора в один из форматов для непосредственной работы предназначена утилита 'PlogConverter.exe', входящая в состав дистрибутива. 'PlogConverter.exe' позволяет выполнять преобразование .plog файлов в следующие форматы:

  • текстовый файл с результатами анализа. Может быть удобен для вывода результатов анализа (например, новых сообщений анализатора) в лог сборочной системы \ сервера непрерывной интеграции;
  • отчёт HTML с кратким описанием результатов анализа. Подходит для рассылки уведомлений электронной почтой;
  • отчёт HTML с сортировкой результатов анализа по разных параметрам и навигацией по исходному коду;
  • CSV таблица с результатами анализа;
  • Tasks файл для просмотра в QtCreator;
  • текстовый файл, содержащий сводную таблицу количества сообщений на разных уровнях\группах диагностик.

Пример запуска утилиты 'PlogConverter.exe' (одной строкой):

PlogConverter.exe test1.plog -o "C:\Results" -r "C:\Test" 
-a GA:1 -t Html

Данная команда преобразует файл 'test1.plog' в формат .html с отображением диагностических правил первого уровня категории GA (диагностики общего назначения). Результат будет записан в директорию 'C:\Results'. Оригинальный .plog файл изменён не будет.

Получить подробную справка по всем параметрам утилиты 'PlogConverter' можно с помощью команды:

PlogConverter.exe --help

Примечание. Утилита 'PlogConverter' поставляется вместе с исходными файлами (C#), которые доступны в архиве 'PlogConverter_src.zip'. Для создания собственного формата вывода результатов анализа можно переиспользовать алгоритм разбора структуры .plog файла.

Более подробно утилита 'PlogConverter' описана в статье "Работа с результатами анализа (.plog файл)".

SonarQube

Результаты статического анализа могут быть импортированы платформой непрерывного анализа и измерения качества кода SonarQube. Для импорта результатов анализа предназначен плагин 'sonar-pvs-studio-plugin', входящий в состав дистрибутива. Использование плагина позволяет добавлять сообщения, найденные анализатором PVS-Studio, в базу сообщений сервера SonarQube. Это, в свою очередь, даёт возможность видеть статистику появления / исправления ошибок, осуществлять навигацию по предупреждениям анализатора, просматривать документацию к диагностическим правилам и многое другое.

Все сообщения PVS-Studio, добавленные в SonarQube, имеют тип Bug. В интерфейсе SonarQube сохранено разделение сообщений по группам диагностик аналогично тому, как это сделано в анализаторе.

Более подробная информация об интеграции результатов анализа в SonarQube приведена в статье "Интеграция результатов анализа PVS-Studio в SonarQube".

Рассылка результатов анализа по электронной почте с помощью BlameNotifier

Эффективным способом оповещения разработчиков о результатах анализа является их рассылка с использованием специализированных утилит, например, SendEmail. При использовании платформы контроля качества кода SonarQube, выполнять рассылку писем можно её средствами.

Ещё одним вариантом оповещения разработчиков является использование утилиты 'BlameNotifier', поставляемой в составе дистрибутива PVS-Studio. Она позволяет формировать вариативные отчёты. Например, разработчики, заложившие код с ошибками в систему контроля версий, получат индивидуальный отчёт. Лидеры команд, руководитель разработки и т.д. могут получить полный лог отчёта, включающий в себя информацию обо всех найденных ошибках и разработчиках, которые эти ошибки допустили.

Следующая команда выведет основную информацию об утилите:

BlameNotifier.exe --help

Более подробно утилита 'BlameNotifier' рассматривается в статье "Работа с результатами анализа (.plog файл)" в разделе "Оповещение разработчиков".

Заключение

Если у вас остались вопросы, пожалуйста, напишите нам на почту: support@viva64.com

Режим инкрементального анализа PVS-Studio

Полный анализ можно регулярно запускать отдельно, например, раз в сутки во время ночных сборок. Однако наибольшего эффекта от использования анализатора можно добиться только за счёт более раннего обнаружения и исправления выявленных им дефектов. То есть самым оптимальным вариантом использования статического анализатора является проверка нового кода сразу после его написания. Такой сценарий работы, несомненно, осложняется необходимостью постоянно вручную запускать проверку для всех модифицированных файлов и каждый раз ждать завершения анализа. Это несовместимо с интенсивной разработкой и отладкой нового кода. Да и просто неудобно. Однако PVS-Studio предлагает решение этой проблемы.

Стоит помнить, что после первой полной проверки проекта желательно просмотреть все диагностические сообщения для нужных файлов и исправить найденные в коде ошибки. А остальные сообщения либо разметить как ложные срабатывания, либо отключить отображение неактуальных для проекта кодов сообщений или групп диагностик, либо подавить оставшиеся срабатывания, и, возможно, вернуться к их правке позже. Такой подход позволит иметь список сообщений, не забитый бессмысленными и ненужными предупреждениями.

Windows: C, C++, C#

Microsoft Visual Studio

Включить режим послесборочного инкрементального анализа можно в меню Extensions > PVS-Studio > Analysis after Build (Modified Files Only):

https://import.viva64.com/docx/manual/IncrementalAnalysis_ru/image1.png

Данный пункт активирован в PVS-Studio по умолчанию.

После активации режима инкрементального анализа PVS-Studio станет автоматически в фоновом режиме производить анализ всех затронутых модификациями файлов сразу после окончания сборки проекта. После окончания инкрементальной сборки, когда запустится анализ, в области уведомлений Windows появится анимированная иконка PVS-Studio:

https://import.viva64.com/docx/manual/IncrementalAnalysis_ru/image2.png

Контекстное меню области уведомлений позволяет на время приостановить (команда Pause) или отменить (команда Abort) текущую проверку.

Анализатор ориентируется на сборочную систему для определения изменившихся файлов, которые необходимо проверить. Полная пересборка проекта приведёт к анализу всех его файлов - используйте инкрементальную сборку для проверки только изменившихся файлов. В случае, если анализатор во время инкрементального анализа обнаружит ошибки в коде, в названии открытой в Visual Studio вкладки окна PVS-Studio отразится число найденных ошибок, и будет показано Windows уведомление:

https://import.viva64.com/docx/manual/IncrementalAnalysis_ru/image3.png

Клик по иконке в области уведомлений (либо по самому уведомлению) откроет окно PVS-Studio Output.

При работе из Visual Studio можно задать ограничение на время работы инкрементального анализа или уровень выводимых предупреждений. Данные настройки можно регулировать в меню PVS-Studio > Options > Special Analyzer Settings > IncrementalAnalysisTimeout и PVS-Studio > Options > Specific Analyzer Settings > IncrementalResultsDisplayDepth.

Command line analyzer for MSBuild projects (PVS-Studio_Cmd.exe)

Режим инкрементального анализа для решений Visual Studio доступен также в модуле командной строки (PVS-Studio_Cmd.exe). Этот режим позволяет ускорить статический анализ на сервере непрерывной интеграции. В нём реализованы подходы, аналогичные подходам MSBuild для инкрементальной сборки.

Настроить инкрементальный анализ на сервере можно с помощью нескольких команд:

PVS-Studio_Cmd.exe ... --incremental Scan ...
MSBuild.exe ... -t:Build ...
PVS-Studio_Cmd.exe ... --incremental Analyze ...

Все режимы работы инкрементального анализа выглядят так:

  • Scan - проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ. Непосредственно анализ выполнен не будет. Этот шаг должен выполняться перед сборкой решения или проекта. Результаты сканирования будут записаны во временные директории .pvs-studio, расположенные в тех же директориях, где находятся проектные файлы. При этом будут учтены изменения, произведенные с момента последней сборки, предыдущая история изменений сохранённая в каталоге .pvs-studio, будет удалена.
  • AppendScan - проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ. Непосредственно анализ выполнен не будет. Этот шаг должен выполняться перед сборкой решения или проекта. Результаты сканирования будут записаны во временные директории .pvs-studio, расположенные в тех же директориях, где находятся проектные файлы. Будут учтены изменения, произведенные с момента последней сборки, а также все предыдущие изменения.
  • Analyze - выполнить инкрементальный анализ. Этот шаг должен выполняться после выполнения шагов Scan или AppendScan, и может выполняться как до, так и после сборки решения или проекта. Статический анализ будет выполнен только для файлов из списка, полученного в результате выполнения команд Scan или AppendScan. Если в настройках PVS-Studio опция 'Remove Intermediate Files' установлена в True, временные директории .pvs-studio будут удалены.
  • ScanAndAnalyze - проанализировать все зависимости для определения того, на каких файлах должен быть выполнен инкрементальный анализ, и сразу же выполнить инкрементальный анализ измененных файлов с исходным кодом. Этот шаг необходимо выполнить перед сборкой проекта\решения. Будут учтены изменения, произведенные с момента последней сборки.

Compiler Monitoring UI

В случае необходимости инкрементального анализа при использовании системы мониторинга компиляции, достаточно "отслеживать" инкрементальную сборку, т.е. компиляцию тех файлов, которые были изменены с момента последней сборки. Этот сценарий использования позволит анализировать только изменённый/новый код.

Такой сценарий использования естественен для системы мониторинга компиляции, т.к. она основана на "отслеживании" запусков компилятора во время сборки проекта, что позволяет получить всю необходимую информацию для запуска анализа на исходных файлах, компиляция которых была отслежена. Следовательно, режимы анализа зависят от того, какая сборка отслеживается: полная или инкрементальная.

Более подробно система мониторинга компиляции описана в статье "Система мониторинга компиляции в PVS-Studio".

Linux/macOS: C, C++

CMake-проекты

Для проверки CMake-проекта можно использовать файл JSON Compilation Database. Для получения необходимого анализатору файла compile_commands.json необходимо добавить один флаг к вызову CMake:

cmake -DCMAKE_EXPORT_COMPILE_COMMANDS=On <src-tree-root>

Для инкрементального анализа такого проекта необходимо добавить флаг --incremental к команде анализа:

pvs-studio-analyzer analyze ... --incremental ...

В каталоге .PVS-Studio будут сохраняться зависимости между файлами и время модификаций, т.к. в этом режиме анализатор работает независимо от сборочной системы. Этот каталог необходимо сохранять для работы этого режима анализа.

Если используемый CMake генератор не поддерживает создание файла compile_commands.json, или генерация такого файла неудобна, можно воспользоваться прямой интеграцией PVS-Studio с CMake - использование модуля прямой интеграции позволит выполнять инкрементальный анализ одновременно с инкрементальной сборкой.

Makefile-проекты

В скрипты сборочной системы Make и подобных можно прописать вызов анализатора рядом с компилятором:

$(CXX) $(CFLAGS) $< ...
pvs-studio --source-file $< ...

В таком случае инкрементальный анализ и инкрементальная сборка будут работать совместно, получая информацию об изменённых файлах от сборочной системы.

Примеры интеграции PVS-Studio в Makefile собраны в репозитории на GitHub: pvs-studio-makefile-examples.

Другие проекты (только для Linux)

Проверить любой проект без интеграции анализатора в сборочную систему можно с помощью следующих команд:

pvs-studio-analyzer trace – make
pvs-studio-analyzer analyze ...

Вместо команды make может быть любая команда запуска сборки проекта со всеми необходимыми параметрами.

В этом режиме анализатор отслеживает и производит логирование дочерних процессов сборочной системы и ищет среди них процессы компиляции. Если собирать проект в режиме инкрементальной сборки, то и проверяться будут только изменённые файлы.

Windows/Linux/macOS: Java

IntelliJ IDEA

Включить режим послесборочного инкрементального анализа можно в меню Analyze > PVS-Studio > Settings > PVS-Studio > Misc > Run incremental analysis on every build:

https://import.viva64.com/docx/manual/IncrementalAnalysis_ru/image4.png

После активации режима инкрементального анализа PVS-Studio станет автоматически в фоновом режиме производить анализ изменённых файлов сразу после окончания сборки проекта. Если PVS-Studio выдаст предупреждения, то они будут выведены в окне PVS-Studio:

https://import.viva64.com/docx/manual/IncrementalAnalysis_ru/image5.png

Maven Plugin

В maven плагине инкрементальный режим включается флажком incremental:

<plugin>
  <groupId>com.pvsstudio</groupId>
  <artifactId>pvsstudio-maven-plugin</artifactId>
  ....
  <configuration>
    <analyzer>
       ....
       <incremental>true</incremental>
       ....
    </analyzer>
  </configuration>
</plugin>

После активации режима инкрементального анализа команда pvsstudio:pvsAnalyze будет запускать анализ только на измененных файлах относительно последнего запуска.

Gradle Plugin

В gradle плагине инкрементальный режим включается аналогичным флажком incremental:

apply plugin: com.pvsstudio.PvsStudioGradlePlugin
pvsstudio {
  ....
  incremental = true
  ....
}

После активации режима инкрементального анализа команда pvsAnalyze будет запускать анализ только на измененных файлах относительно последнего запуска.

Дополнительные ссылки

Интеграция результатов анализа PVS-Studio в SonarQube

SonarQube - это открытая платформа для обеспечения непрерывного контроля качества исходного кода, поддерживающая большое количество языков программирования и позволяющая получать отчеты по таким метрикам, как дублирование кода, соответствие стандартам кодирования, покрытие тестами, сложность кода, потенциальные ошибки и т.д. SonarQube удобно визуализирует результаты анализа и позволяет отслеживать динамику развития проекта во времени.

Демонстрация возможностей платформы SonarQube доступна по адресу sonarqube.org.

Для импорта результатов анализа в SonarQube PVS-Studio предоставляет плагин. Использование плагина позволяет добавлять сообщения, найденные анализатором PVS-Studio, в базу сообщений сервера SonarQube. С помощью Web интерфейса SonarQube можно фильтровать сообщения, осуществлять навигацию по коду для анализа ошибок, назначать задачи на исполнителей и контролировать их выполнение, анализировать динамику количества ошибок и оценивать уровень качества кода проекта.

Системные требования

  • Операционная система: Windows, Linux; macOS
  • Версия Java: 8 и выше;
  • SonarQube 6.7 LTS или выше;
  • Анализатор PVS-Studio;
  • Enterprise-лицензия PVS-Studio.

Плагины PVS-Studio и их установка

Пользователям PVS-Studio доступны следующие плагины для SonarQube:

  • sonar-pvs-studio-plugin.jar - плагин для импорта результатов PVS-Studio в проект на сервере SonarQube;
  • sonar-pvs-studio-lang-plugin.jar - плагин, позволяющий создавать профиль (quality profile) с языком C/C++/C#. Данный плагин предоставляется для совместимости перехода со старых версий SonarQube плагинов PVS-Studio с сохранением ранее полученных метрик\статистики, в будущих релизах его поддержка может быть прекращена. Если вы создаёте новый проект, используйте профиль с одним из стандартных языков (C++, C#, Java);

Инструкция по установке и запуску сервера SonarQube доступна на странице Installing the Server.

После установки сервера SonarQube скопируйте плагин (sonar-pvs-studio-plugin.jar) в следующую директорию:

SONARQUBE_HOME/extensions/plugins

В зависимости от языка, для которого вы загружаете результаты анализа, установите также соответствующие плагины из списка (часть из них может быть установлена по умолчанию, в зависимости от используемой вами редакции SonarQube):

  • SonarC++ plugin (GitHub)
  • SonarC plugin (GitHub)
  • SonarC# plugin (Marketplace)
  • SonarJava plugin (Marketplace)
  • SonarCFamily (SQ Developer Edition)

После этого перезапустите сервер SonarQube.

Создание и настройка Quality Profile

Quality Profile - это коллекция диагностик, которые выполняются во время анализа. Вы можете включать диагностики PVS-Studio в существующие профили, либо создать новый. Профиль привязывается к конкретному языку программирования, но вы можете создавать несколько профилей с разными наборами правил. Все действия доступны пользователям из группы sonar-administrators.

Создать новый профиль можно в меню Quality Profiles -> Create:

https://import.viva64.com/docx/manual/SonarQube_ru/image1.png

Для включения диагностик анализатора в активный профиль, выберите интересующий вас репозиторий в меню Rules -> Repository:

https://import.viva64.com/docx/manual/SonarQube_ru/image2.png

Далее добавьте все диагностические правила в свой профиль, нажав на кнопку Bulk Change, или выберите конкретные правила вручную.

Окно активации диагностик выглядит следующим образом:

https://import.viva64.com/docx/manual/SonarQube_ru/image3.png

Вы также можете фильтровать правила по тегам, прежде чем выбрать их для профиля:

https://import.viva64.com/docx/manual/SonarQube_ru/image4.png

После создания/настройки соответствующего профиля, назначьте один из них профилем по умолчанию:

https://import.viva64.com/docx/manual/SonarQube_ru/image5.png

Профиль по умолчанию запускается на файлах для указанного языка программирования. Профили не обязательно делить по используемым утилитам. Вы можете создать единый профиль для вашего проекта, добавив туда диагностические правила из разных утилит.

При выходе новой версии PVS-Studio могут добавиться новые диагностики, поэтому нужно обновить версию плагина на сервере SonarQube и добавить новые диагностики в Quality Profile, который использует диагностики PVS-Studio. Настройка автоматического обновления описана ниже, в отдельном разделе.

Анализ кода и импорт результатов в SonarQube

Для импорта результатов анализа в SonarQube используется утилита SonarQube Scanner. Для работы ей требуется конфигурационный файл с именем sonar-project.properties, размещённый в корневом каталоге проекта. Конфигурационный файл содержит настройки для анализа заданного проекта, при этом часть или все настройки можно перенести в параметры запуска утилиты SonarQube Scanner.

Далее будут рассмотрены типовые режимы запуска сканера для импорта результатов анализа PVS-Studio в SonarQube на разных платформах. SonarQube Scanner будет автоматически подхватывать конфигурационный файл с именем sonar-project.properties в текущей директории запуска.

Windows: C, C++, C#

MSBuild-проекты проверяются с помощью утилиты PVS-Studio_Cmd.exe.

Вариант 1

Одним запуском PVS-Studio_Cmd вы можете получить отчёт анализатора и конфигурационный файл sonar-project.properties:

PVS-Studio_Cmd.exe ... -o Project.plog --sonarqubedata ...

Команда запуска сканера будет выглядеть следующим образом:

sonar-scanner.bat ^
  -Dsonar.projectKey=ProjectKey ^
  -Dsonar.projectName=ProjectName ^
  -Dsonar.projectVersion=1.0 ^
  -Dsonar.pvs-studio.reportPath=Project.plog

Вариант 2

Если вы используете SonarQube Scanner for MSBuild, то используете следующие команды для анализа проекта и загрузки результатов в SonarQube:

SonarScanner.MSBuild.exe begin ... /d:sonar.pvs-studio.reportPath=Project.plog
MSBuild.exe Project.sln /t:Rebuild ...
PVS-Studio_Cmd.exe -t Project.sln ... -o Project.plog
SonarScanner.MSBuild.exe end

Windows, Linux, macOS: Java

Добавьте следующие строки в проверяемый анализатором PVS-Studio Java проект (в зависимости от типа проверяемого проекта):

Maven

<outputType>xml</outputType>
<outputFile>output.xml</outputFile>
<sonarQubeData>sonar-project.properties</sonarQubeData>

Gradle

outputType = 'xml'
outputFile = 'output.xml'
sonarQubeData='sonar-project.properties'

После завершения работы Java анализатора конфигурационный файл SonarQube также будет создан автоматически.

Команда запуска сканера будет выглядеть следующим образом:

sonar-scanner.bat ^
  -Dsonar.projectKey=ProjectKey ^
  -Dsonar.projectName=ProjectName ^
  -Dsonar.projectVersion=1.0 ^
  -Dsonar.pvs-studio.reportPath=output.xml

Linux, macOS: C, C++

Конфигурационный файл после проверки проекта необходимо создать самостоятельно, например, с таким содержимым:

sonar.projectKey=my:project
sonar.projectName=My project
sonar.projectVersion=1.0
sonar.pvs-studio.reportPath=report.xml
sonar.sources=.

Команды запуска конвертера и сканера будут выглядеть следующим образом:

plog-converter ... -t xml - o report.xml ...
sonar-scanner.sh \
  -Dsonar.projectKey=ProjectKey \
  -Dsonar.projectName=ProjectName \
  -Dsonar.projectVersion=1.0 \
  -Dsonar.pvs-studio.reportPath=report.xml

sonar-project.properties

Для более глубокой настройки анализа своего проекта, вы можете самостоятельно составить конфигурационный файл из следующих настроек (или отредактировать создаваемый по умолчанию файл при проверке MSBuild и Java проектов):

  • sonar.pvs-studio.reportPath - путь к отчёту анализатора в формате .plog (для MSBuild проектов) или .xml;
  • sonar.pvs-studio.licensePath - путь к лицензии анализатора PVS-Studio (если проверяется MSBuild проект, вы можете передать эту настройку с помощью параметра sonar.pvs-studio.settingsPath);
  • sonar.pvs-studio.sourceTreeRoot - путь к директории проекта на текущем компьютере, если отчёт анализатора был получен на другом компьютере, Docker-контейнере и т.п. Задание данного пути позволяет передавать в sonar.pvs-studio.reportPath отчёт, сгенерированный с относительными путями (если проверяется MSBuild проект, вы можете передать эту настройку с помощью параметра sonar.pvs-studio.settingsPath);
  • sonar.pvs-studio.settingsPath - путь к Settings.xml для MSBuild проектов, проверяемых на Windows. В этом файле уже содержится информация о licencePath и sourceTreeRoot, поэтому эти параметры можно не указывать отдельно;
  • sonar.pvs-studio.cwe - включает добавление CWE ID к предупреждениям анализатора. По умолчанию эта опция выключена. Используйте значение active для включения;
  • sonar.pvs-studio.misra - включает добавление идентификатора MISRA к предупреждениям анализатора. По умолчанию эта опция выключена. Используйте значение active для включения;
  • sonar.pvs-studio.language - включает языковой плагин C/C++/C#. По умолчанию эта опция выключена. Используйте значение active для включения. Используйте данную настройку, если вы используете профиль с языком C/C++/C#, добавляемым отдельным плагином PVS-Studio. Данный плагин предоставляется для совместимости перехода со старых версий SonarQube плагинов PVS-Studio с сохранением ранее полученных метрик\статистики, в будущих релизах его поддержка может быть прекращена.

Описание остальных стандартных параметров конфигурации сканера доступно в общей документации SonarQube.

Многомодульный проект

Когда директории подпроектов расположены на разных уровнях, загрузить в SonarQube результаты анализа нескольких подпроектов в один проект со стандартными настройками становится невозможным. Это связано с тем, что для такой структуры подпроектов требуется дополнительная настройка индексатора в утилите SonarScanner.

Правильно настроить такой проект можно с помощью модулей, где каждый модуль настраивается для одного подпроекта:

sonar.projectKey=org.mycompany.myproject
sonar.projectName=My Project
sonar.projectVersion=1.0
sonar.sources=src

sonar.modules=module1,module2

module1.sonar.projectName=Module 1
module1.sonar.projectBaseDir=modules/mod1

module2.sonar.projectName=Module 2
module2.sonar.projectBaseDir=modules/mod2

Для указания пути к файлу с результатами анализа PVS-Studio есть 2 пути.

Первый способ

Указать разные отчёты для модулей:

....
sonar.modules=module1,module2

module1.sonar.projectName=Module 1
module1.sonar.projectBaseDir=modules/mod1
module1.sonar.pvs-studio.reportPath=/path/to/report1.plog

module2.sonar.projectName=Module 2
module2.sonar.projectBaseDir=modules/mod2
module2.sonar.pvs-studio.reportPath=/path/to/report2.plog

Второй способ

Указать один отчёт на уровне проекта:

sonar.projectKey=org.mycompany.myproject
sonar.projectName=My Project
sonar.projectVersion=1.0
sonar.sources=src
sonar.pvs-studio.reportPath=/path/to/report.plog

sonar.modules=module1,module2
....

В этом случае каждый модуль загрузит из отчёта только те предупреждения, которые относятся к нему. К сожалению, на файлы из других модулей будет выдан WARN об отсутствии файлов в вывод утилиты SonarScanner, но все результаты анализа будет загружены корректно.

Исследователям безопасности приложений

Со всеми возможности анализатора по поиску потенциальных уязвимостей в коде вы можете ознакомиться на странице PVS-Studio SAST (Static Application Security Testing).

Информация о безопасности проверяемого кода, предоставляемая анализатором PVS-Studio, дополнительно помечается в отображаемых SonarQube результатах анализа.

Теги cwe, cert, misra

В меню Issues -> Tag или Rules -> Tag доступны следующие теги для группировки предупреждений PVS-Studio по разным стандартам безопасности:

  • misra
  • cert
  • cwe

Также вы можете выбрать конкретный CWE ID, если такой доступен (если сообщение анализатора соответствует нескольким идентификаторам CWE, оно будет отмечено одним общим тегом cwe - используйте префиксы в тексте предупреждений для фильтрации таких идентификаторов):

https://import.viva64.com/docx/manual/SonarQube_ru/image6.png

Префиксы CWE и MISRA у предупреждений

В конфигурационном файле sonar-project.properties доступны следующие опции:

sonar.pvs-studio.cwe=active
sonar.pvs-studio.misra=active

Они включают режим добавления идентификаторов CWE и MISRA к предупреждениям анализатора. Выглядит это следующим образом:

https://import.viva64.com/docx/manual/SonarQube_ru/image7.png

Возможность фильтровать предупреждения по соответствующим тегам доступна всегда и не зависит от указанных опций.

Статистика по найденным CWE и MISRA

На вкладке Projects -> Your Project -> Measures доступны различные метрики кода, вычисляемые после каждого запуска анализа. Всю собираемую информацию можно выводить в полезные графики. В секции Security вы можете следить за количеством предупреждений, выдаваемых на проект с пометкой CWE и MISRA:

https://import.viva64.com/docx/manual/SonarQube_ru/image8.png

Остальные, общие метрики сообщений анализатора PVS-Studio, доступны в отдельной секции PVS-Studio.

Дополнительные возможности плагина PVS-Studio

Большинство действий, доступных для пользователей SonarQube, являются стандартными для этой платформы. Например, просмотр и сортировка результатов анализа, изменение статуса предупреждения и т.п. Поэтому в этом разделе будут описаны только дополнительные возможности, появляющиеся с установкой плагина PVS-Studio.

Сортировка предупреждений по группам

Предупреждения PVS-Studio делятся на несколько групп, из которых не все могут быть интересны для конкретного проекта. Поэтому вы можете фильтровать диагностики по следующим тегам при создании профиля или просмотре результатов анализа:

Группа диагностик в PVS-Studio

Тег в SonarQube

Диагностики общего назначения

pvs-studio#ga

Диагностики микро-оптимизаций

pvs-studio#op

Диагностики 64-битных ошибок

pvs-studio#64

Стандарт MISRA

pvs-studio#misra

Диагностики, реализованные по запросам пользователей

pvs-studio#cs

Проблемы при работе анализатора кода

pvs-studio#fails

И стандартные теги, которые используются для предупреждений PVS-Studio:

Стандарты контроля качества кода

Тег в SonarQube

Стандарт CWE

cwe

Стандарт CERT

cert

Стандарт MISRA

misra

Стандартные теги SonarQube, в отличии от группы тегов pvs-studio#, могут включать, в зависимости от используемого quality профиля, сообщения и от других инструментов, помимо PVS-Studio.

Просмотр метрик кода

На вкладке Projects -> Your Project -> Measures доступны различные метрики кода, вычисляемые после каждого запуска анализа. С плагином добавляется секция PVS-Studio, где вы можете найти полезную информацию для проекта и строить графики:

https://import.viva64.com/docx/manual/SonarQube_ru/image9.png

Предварительная настройка анализатора

При работе на большой кодовой базе, анализатор неизбежно генерирует большое количество предупреждений. При этом часто нет возможности поправить все предупреждения сразу. Для того, чтобы иметь возможность сконцентрироваться на правке наиболее важных предупреждений и не "засорять" статистику, можно провести предварительную настройку анализатора и фильтрацию лога до запуска SonarQube Scanner. Это можно сделать несколькими способами.

1. Анализ можно сделать менее "шумным" с помощью настройки No Noise. Она позволяет полностью отключить генерацию предупреждений низкого уровня достоверности (Low Certainty, третий уровень предупреждений). После перезапуска анализа, сообщения этого уровня полностью пропадут из вывода анализатора. Для включения этой настройки в анализаторе, воспользуйтесь окном настроек "Specific Analyzer Settings" в Windows и общей документацией для Linux и macOS.

2. Анализ можно ускорить, исключив из проверки внешние библиотеки, код тестов и т.д. Для добавления файлов и каталогов в исключения, воспользуйтесь окном настроек "Don't Check Files" в Windows и общей документацией для Linux и macOS.

3. Если вам нужен дополнительный контроль над тем, какие сообщения анализатора будут попадать в отображаемые результаты, например, по уровню достоверности или кодам ошибок, воспользуйтесь утилитой для фильтрации и преобразования результатов (Plog Converter) на соответствующей платформе.

4. Если вам необходимо изменить важность предупреждения, это делается в настройках самого анализатора, а не в SonarQube. Сообщения PVS-Studio имеют следующие уровни достоверности: High, Medium, Low и Fails. В SonarQube им соответствуют уровни Critical, Major, Minor и Info. Изменение уровней описано на странице "Дополнительная настройка диагностик"

Автоматическое обновление плагинов PVS-Studio

Автоматизировать процесс обновления позволяет SonarQube Web Api. Предположим, на вашем билд-сервере настроена система автоматического обновления PVS-Studio (как это описано в статье Развертывание PVS-Studio в больших командах). Для того, чтобы обновить плагины PVS-Studio и добавить новые диагностики в Quality Profile без использования веб-интерфейса, выполните следующие шаги (пример для Windows, на других ОС данная процедура выполняется аналогично):

  • Скопируйте файл sonar-pvs-studio-plugin.jar из директории установки PVS-Studio в директорию $SONARQUBE_HOME\extensions\plugins.
  • Перезапустите сервер SonarQube.

Допустим, сервер SonarQube установлен в директории C:\Sonarqube\ и запущен как сервис. PVS-Studio установлена в директории C:\Program Files (x86)\PVS-Studio\. Тогда скрипт для автоматического обновления дистрибутива PVS-Studio и плагина sonar-pvs-studio-plugin будет иметь вид:

set PVS-Studio_Dir="C:\Program Files (x86)\PVS-Studio"
set SQDir="C:\Sonarqube\extensions\plugins\"

rem Update PVS-Studio
cd /d "C:\temp\"
xcopy %PVS-Studio_Dir%\PVS-Studio-Updater.exe . /Y
call PVS-Studio-Updater.exe /VERYSILENT /SUPPRESSMSGBOXES
del PVS-Studio-Updater.exe

rem Stop the SonarQube server
sc stop SonarQube

rem Wait until the server is stopped
ping -n 60 127.0.0.1 >nul

xcopy %PVS-Studio_Dir%\sonar-pvs-studio-plugin.jar %SQDir% /Y

sc start SonarQube

rem Wait until the server is started
ping -n 60 127.0.0.1 >nul

  • Определите ключ Quality Profile, в котором необходимо активировать диагностики. Получить этот ключ можно с помощью запроса GET api/qualityprofiles/search, например (одной строкой):
curl http://localhost:9000/api/qualityprofiles/search
-v -u admin:admin

Ответ сервера имеет следующий формат:

{
  "profiles": [
    {
     "key":"c++-sonar-way-90129",
     "name":"Sonar way",
     "language":"c++",
     "languageName":"c++",
     "isInherited":false,
     "isDefault":true,
     "activeRuleCount":674,
     "rulesUpdatedAt":"2016-07-28T12:50:55+0000"
    },
    {
     "key":"c-c++-c-pvs-studio-60287",
     "name":"PVS-Studio",
     "language":"c/c++/c#",
     "languageName":"c/c++/c#",
     "isInherited":false,
     "isDefault":true,
     "activeRuleCount":347,
     "rulesUpdatedAt":"2016-08-05T09:02:21+0000"
    }
  ]
}

Допустим, нам нужно добавить новые диагностики в профиль PVS-Studio для языка 'c/c++/c#'. Его ключом является значение c-c++-c-pvs-studio-60287.

  • Выполните POST-запрос api/qualityprofiles/activate_rules и укажите параметры profile_key (обязательный параметр) и tags. Обязательный параметр profile_key определяет ключ профиля в SonarQube, в котором будут активированы диагностики. В рассматриваемом примере этот параметр имеет значение c-c++-c-pvs-studio-60287.

Обратите внимание на то, что ключ профиля может содержать специальные символы, и при отправке его в POST-запросе нужно произвести экранирование URL символов. Так, ключ профиля c-c++-c-pvs-studio-60287 должен быть преобразован в c-c%2B%2B-c-pvs-studio-60287

В параметре tags передайте теги диагностик, которые нужно активировать в профиле. Чтобы активировать все диагностики PVS-Studio, укажите тег pvs-studio.

В результате, запрос на добавление всех диагностик в профиль PVS-Studio будет иметь вид (одной строкой):

curl --request POST -v -u admin:admin -data
"profile_key=c-c%2B%2B-c-pvs-studio-60287&tags=pvs-studio"
http://localhost:9000/api/qualityprofiles/activate_rules

Рекомендации и ограничения

  • Сервер SonarQube по умолчанию удаляет сообщения, закрытые более 30 дней назад. Мы рекомендуем отключить эту функцию, чтобы по истечению длительного периода времени (года, например) иметь возможность проанализировать, сколько сообщений, найденных PVS-Studio, было исправлено;
  • Если в файле sonar-project.properties определены модули, и у вас есть отдельный отчёт анализатора для каждого модуля, то необходимо объединить отчёты в один с помощью утилиты PlogConverter и указать отчёт один раз в sonar.pvs-studio.reportPath.
  • Для анализа проектов MSBuild разработчики SonarQube рекомендуют использовать SonarQube Scanner for MSBuild. Этот сканер представляет собой обертку над стандартным сканером SonarQube и облегчает процесс создания конфигурационного файла сканера sonar-project.properties, автоматически добавляя в него модули (проекты в решении) и записывая пути до исходных файлов, которые необходимо проанализировать. Однако мы столкнулись с ограничениями, из-за которых для сложных проектов создаются некорректные конфигурационные файлы, поэтому для импорта результатов анализа PVS-Studio мы рекомендуем использовать стандартный сканер SonarQube.
  • Все исходные файлы для анализа должны располагаться на одном диске. Это ограничение налагается платформой SonarQube. Исходные файлы, расположенные на дисках, отличных от диска, указанного в свойстве sonar.projectBaseDir, не будут проиндексированы, и сообщения, найденные в этих файлах, будут проигнорированы.

Статистика работы анализатора (графики)

Введение

Анализатор PVS-Studio позволяет собирать статистику своей работы - количество найденных сообщений (включая подавленные) на разных уровнях и группах диагностик. Собранная статистика может быть отфильтрована и отображена в виде графика в документе Microsoft Excel, показывающего динамику изменения сообщений в проверяемом проекте.

Сбор статистики запусков анализатора

PVS-Studio может сохранять статистику запусков при проверке кода с помощью плагина к Microsoft Visual Studio (начиная с версии Visual Studio 2010). Для включения сохранения статистики можно воспользоваться настройкой Save Solution Statistics, доступной на странице настроек Specific Analyzer Settings, которую можно открыть через пункт меню плагина 'PVS-Studio|Options...'.

Статистика записывается в директории '%AppData%/PVS-Studio/Statistics'. Для каждого проверяемого решения Visual Studio будет создана поддиректория с именем этого решения. Для каждого запуска проверки решения по окончании анализа будет записан отдельный файл статистики с результатами проверки (при использовании режима проверки из командной строки для Visual Studio проектов статистика также будет вестись). Файл статистики содержит информацию о количестве найденных сообщений (новых и скрытых с помощью механизма подавления сообщений) в каждой группе диагностических правил PVS-Studio (General Analysis, Optimization, 64-bit Analysis), для каждой ошибки и уровня достоверности сообщения. Сообщения, размеченные как ложные срабатывания, в статистику не попадают.

Каждый запуск проверки решения Visual Studio записывается в файл с расширением xml.zip - обычный zip архив, содержащий внутри xml документ простого формата. Благодаря открытому формату, файлы статистики можно как интерпретировать самостоятельно, так и использовать UI, предоставляемый плагином PVS-Studio, который будет описан ниже.

Фильтрация статистики и отображение в Microsoft Excel

PVS-Studio предоставляет интерфейс для фильтрация собранной статистики запусков анализа и её отображения средствами Microsoft Excel.

Для использования данного диалога необходимо присутствие в системе Microsoft Excel (версии 2007 и выше), а также пакета Visual Studio Tools for Office (устанавливается со средой Visual Studio по умолчанию).

Открыть диалог фильтрации статистики можно с помощью пункта меню 'PVS-Studio|Analysis Statistics...' (доступен также в приложении C and C++ Compiler Monitoring UI):

https://import.viva64.com/docx/manual/ExcelStatistics_ru/image1.png

Рисунок 1 - Диалог фильтрации статистики запусков анализатора PVS-Studio

Checkbox 'Include Suppressed Messages' позволяет показать\скрыть сообщения анализатора, размеченные, как подавленные. Сообщения, отключённые на странице настроек Detectable Errors (PVS-Studio|Options...), также отфильтровываются при построении Excel документа (сами файлы статистики xml.zip содержат полную информацию о всех кодах ошибок).

Диалог фильтрации статистики PVS-Studio берёт только самые "свежие" данные за каждый день, т.е. если анализ запускался несколько раз в течении одного дня, будет использован файл статистики с самым поздним временем создания (записано внутри xml файла статистики). Тем не менее, статистика будет сохранена для каждого из запусков, при необходимости она доступна в директории '%AppData%/PVS-Studio/Statistics/%SolutionName%'.

После выбора необходимых решений в списке, включения фильтров и задания интересующего временного диапазона, Excel документ, содержащий отфильтрованную по выбранным критериям статистику, можно открыть, нажав кнопку 'Show in Excel' (рисунок 2).

https://import.viva64.com/docx/manual/ExcelStatistics_ru/image2.png

Рисунок 2 - Статистика по группам сообщений анализатора

График 'по группам сообщений' показывает динамику изменения общего количества сообщений для каждой из групп анализаторов, в соответствии с выбранными ранее фильтрами.

Открытые через диалог PVS-Studio графики являются обычными Excel документами, в которых доступна вся мощь интерфейса Excel (фильтрация, масштабирование и т.п.), которые можно сохранить для дальнейшего использования.

Автоматическое развёртывание PVS-Studio

В данной статье рассматривается работа в среде Windows. Работа в среде Linux описана в статье "Как запустить PVS-Studio в Linux".

Автоматическое развертывание

Для установки PVS-Studio требуются права администратора.

Автоматическая установка выполняется указанием дополнительных параметров командной строки:

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/norestart /nocloseapplications

PVS-Studio может потребоваться перезагрузка компьютера в случае, например, если обновляемые файлы были заблокированы. Для установки без перезагрузки необходимо использовать флаг 'NORESTART'. Обратите внимание, что без этого флага при запуске установщика PVS-Studio в silent режиме перезагрузка может произойти без предварительных уведомлений или диалогов.

По умолчанию будут установлены все доступные компоненты PVS-Studio. В случае, если это не желательно, возможно указание компонентов для установки с помощью флага 'COMPONENTS' (далее перечислены все доступные компоненты):

PVS-Studio_setup.exe /verysilent /suppressmsgboxes 
/nocloseapplications /norestart /components= Core, 
Standalone,MSVS,MSVS\2010,MSVS\2012,MSVS\2013,MSVS\2015,MSVS\2017,
MSVS\2019,IDEA,JavaCore,Rider

Краткое описание компонентов:

  • компоненты с префиксом 'MSVS' в названии соответствуют плагинам среды Microsoft Visual Studio;
  • компонент 'Core' является обязательным и содержит command-line ядро анализатора, без которого не смогут работать IDE модули расширения;
  • компонент Standalone задаёт установку системы отслеживания вызовов компилятора, позволяющую проверить любой C, C++ проект, если этот проект использует один из поддерживаемых компиляторов;
  • компонент 'IDEA' соответствует плагину PVS-Studio для среды разработки IntelliJ IDEA;
  • компонент 'JavaCore' соответствует ядру анализатора для Java;
  • компонент 'Rider' соответствует плагину PVS-Studio для среды разработки Rider.

Во время установки PVS-Studio все экземпляры Visual Studio / IntelliJ IDEA / Rider должны быть выключены, однако для предотвращения потерь несохраненных документов установочный пакет не выгружает Visual Studio / IntelliJ IDEA / Rider самостоятельно.

Инсталлятор завершит работу с кодом завершения 100 в случае, если не сможет установить модуль расширения (*.vsix) для какой-либо из выбранных версий Visual Studio.

Утилита PVS-Studio-Updater.exe позволяет проверить наличие обновлений анализатора, а в случае их наличия, скачать и установить их на локальной машине. Для запуска утилиты обновления в "тихом" режиме можно использовать те же параметры, что и для дистрибутива:

PVS-Studio-Updater.exe /VERYSILENT /SUPPRESSMSGBOXES

В случае отсутствия обновлений на сервере, утилита завершит работу с кодом 0. Т.к. PVS-Studio-Updater.exe производит локальную установку PVS-Studio, во время его работы в системе также не должен быть запущен процесс devenv.exe.

Если в вашей системе используется прокси с авторизацией, утилита PVS-Studio-Updater.exe предложит вам ввести учетные данные для авторизации. Если учетные данные были введены корректно, PVS-Studio-Updater.exe сохранит их в Windows Credential Manager, и в дальнейшем будет использовать эти учетные данные для авторизации на прокси. Если вы хотите использовать утилиту с прокси без авторизации, вы можете сделать это с помощью флага proxy (/proxy=ip:port).

Установка с использованием пакетного менеджера Chocolatey

Ещё один возможный вариант установки заключается в использовании менеджера пакетов Chocolatey. При использовании этого варианта установке в системе уже должен быть установлен сам пакетный менеджер.

Команда установки последней доступной версии пакета PVS-Studio:

choco install pvs-studio

Команда установки конкретной версии пакета PVS-Studio:

choco install pvs-studio --version=7.05.35617.2075

При установке пакета также можно задать список устанавливаемых компонентов по аналогии с перечисленными в разделе "Автоматическое развёртывание" данного документа. Для указания компонентов используется флаг '--package-parameters'. Компоненты эквивалентны описанным выше и отличаются только синтаксисом некоторых параметров:

  • Standalone;
  • JavaCore;
  • IDEA;
  • Rider;
  • MSVS2010;
  • MSVS2012;
  • MSVS2013;
  • MSVS2015;
  • MSVS2017;
  • MSVS2019.

По умолчанию устанавливается только компонент 'Core'. При перечислении компонентов установки 'Core' указывать не нужно.

Пример команды, которая установит анализатор с компонентами 'Core' и 'Standalone':

choco install pvs-studio --package-parameters="'/Standalone'"

Установка лицензий и настройка приложения

Способы ввода лицензии при использовании различного окружения описаны в разделе документации "Как ввести лицензию PVS-Studio, и что делать дальше".

При развертывании на большое количество машин можно установить лицензию без ручного ввода ключа. Для этого необходимо скопировать файл настроек в папку, находящуюся в профиле пользователя.

Если несколько пользователей используют один и тот же компьютер, лицензия должна быть скопирована для каждого.

Расположение файла настроек по умолчанию:

%USERPROFILE%\AppData\Roaming\PVS-Studio\Settings.xml

Этот файл можно редактировать любым текстовым редактором - это простой xml-файл. Следует отметить, что некоторые настройки могут отсутствовать в этом файле. В этом случае будут применены настройки по умолчанию.

Ускорение анализа C/C++ кода с помощью систем распределённой сборки (IncrediBuild)

Для ускорения прохождения анализа можно использовать системы распределённой сборки, например, IncrediBuild. Анализ C/C++ кода в PVS-Studio можно разделить на 2 этапа: препроцессирование и собственно анализ. Каждый из этих этапов может быть выполнен удалённо системой распределённой сборки. Для анализа каждого проверяемого C/C++ компилируемого файла, PVS-Studio запускает сначала внешний препроцессор, а затем непосредственно C++ анализатор. Каждый такой процесс может быть выполнен удалённо.

В зависимости от типа проверяемого проекта, анализ PVS-Studio запускается либо через утилиту PVS-Studio_Cmd.exe (для MSBuild проектов), либо с помощью утилиты для отслеживания вызовов компилятора CLMonitor.exe \ Standalone.exe (для любой сборочной системы). Далее, одна из этих утилит будет запускать для каждого проверяемого файла сначала препроцессор (cl.exe, clang.exe для Visual C++ проектов, для остальных – тот же процесс, что использовался при компиляции), а затем C++ анализатор PVS-Studio.exe.

Задание для настройки 'ThreadCount' значения, большего '16' (или большего, чем количество ядер процессора, если у процессора более 16 ядер), доступно только при наличии Enterprise лицензии PVS-Studio. Для заказа лицензии, пожалуйста, напишите нам.

Данные процессы запускаются параллельно, в зависимости от настройки PVS-Studio|Options...|Common AnalyzerSettings|ThreadCount. Увеличивая количество параллельно проверяемых файлов с помощью этой настройки, и разнеся выполнение этих процессов дополнительно на удалённые машины, можно существенно (в несколько раз) сократить полное время анализа.

Пример настройки IncrediBuild

Приведём пример ускорения анализа PVS-Studio c использованием распределённой системы IncrediBuild. Для этого нам потребуется консольная утилита управления IBConsole. Мы будем использовать интерфейс для автоматического перехвата (Automatic Interception Interface), который позволяет удалённо выполнять любой процесс, перехваченный этой системой. Запуск утилиты IBConsole для распределённого анализа с помощью PVS-Studio будет иметь следующий вид:

ibconsole /command=analyze.bat /profile=profile.xml

Файл analyze.bat должен содержать строку запуска анализатора, PVS-Studio_Cmd.exe или CLMonitor.exe, со всеми необходимыми им параметрами (более подробно можно посмотреть в соответствующем разделе документации). Файл profile.xml содержит конфигурацию для интерфейса автоматического перехвата. Вот пример такой конфигурации для анализа MSBuild проекта с помощью PVS-Studio_Cmd.exe:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<Profile FormatVersion="1">
  <Tools>
    <Tool Filename="PVS-Studio_Cmd" AllowIntercept="true" />
    <Tool Filename="cl" AllowRemote="true" />
    <Tool Filename="clang" AllowRemote="true" />
    <Tool Filename="PVS-Studio" AllowRemote="true" />
  </Tools>
</Profile>

Посмотрим, что означает каждая запись в этом файле. Мы видим, что для PVS-Studio_Cmd задан атрибут AllowIntercept со значением 'true'. Это означает, что процесс с таким именем не будет сам запускаться распределённо, но система автоматического перехвата будет следить за порождаемыми этим процессом дочерними процессами.

Для процессов препроцессора cl и clang и C/C++ анализатора PVS-Studio задан атрибут AllowRemote. Это означает, что процессы с такими именами, будучи отловленными у процессов с AllowIntercept, будут потенциально выполнены на других (удалённых) агентах IncrediBuild.

Перед запуском IBConsole необходимо задать настройку PVS-Studio|Options...|Common AnalyzerSettings|ThreadCount в соответствии с суммарным количеством ядер, доступных на всех IncrediBuild агентах. Если этого не сделать, эффекта от использования IncrediBuild не будет!

Примечание: во время анализа Visual C++ проектов, PVS-Studio использует clang.exe, поставляемый в дистрибутиве PVS-Studio, для препроцессирования C/C++ файлов перед анализом, вместо препроцессора cl.exe. Это сделано для ускорения препроцессирования, т.к. clang работает быстрее, чем cl. Некоторые старые версии IncrediBuild выполняют распределённый запуск препроцессора clang.exe не совсем корректно, что приводит к ошибкам препероцессирования. Поэтому, clang не стоит прописывать в файле конфигурации IBConsole, если ваша версия IncrediBuild работает с clang некорректно.

Используемый тип препроцессора во время анализа задаётся настройкой PVS-Studio|Options...|Common AnalyzerSettings|Preprocessor. Если выбрать для этой настройки значение 'VisualCpp', PVS-Studio будет использовать для препроцессирования только cl.exe, который будет выполняться распределённо, но медленне чем clang, который распределённо выполняться не может. Данную настройку стоит выбрать в зависимости от типа проекта и количества доступных для анализа агентов – при большом количестве агентов выбор VisualCpp будет оправдан. При небольшом количестве агентов, локальное препроцессирование с помощью clang может оказаться быстрее.

Для распределённой проверки с помощью CLMonitor / Compiler Monitoring UI (Standalone.exe), конфигурационный файл необходимо изменить следующим образом: PVS-Studio_Cmd заменить на CLMonitor или Standalone (в зависимости от того, запускается ли проверка из командной строки или из UI), cl, при необходимости, заменить на тот тип препроцессора, который используется при сборке (gcc, clang). Например:

<?xml version="1.0" encoding="UTF-8" standalone="no" ?>
<Profile FormatVersion="1">
  <Tools>
    <Tool Filename="CLMonitor" AllowIntercept="true" />
    <Tool Filename="gcc" AllowRemote="true" />
    <Tool Filename="PVS-Studio" AllowRemote="true" />
  </Tools>
</Profile>

При задании настройки ThreadCount следует помнить, что машина-координатор анализа (т.е. та, на которой будет работать PVS-Studio_Cmd/CLMonitor/Standalone) будет заниматься обработкой результатов, приходящих ото всех процессов PVS-Studio.exe. Данная задача сейчас не может быть распределена – поэтому, особенно когда ThreadCount задаётся очень большим (более 50 процессов одновременно), стоит подумать о том, чтобы "разгрузить" машину-координатор от непосредственно задач анализа (т.е. выполнения процессов анализатора и препроцессора). Это можно сделать с помощью флага IBConsole '/AvoidLocal' или в настройках локального агента IncrediBuild на машине координаторе.

Установка и обновление PVS-Studio в Linux

PVS-Studio распространяется в виде Deb/Rpm пакетов или архива. Воспользовавшись установкой из репозитория, вы сможете получать обновления о выходе новой версии программы.

В дистрибутиве содержатся следующие файлы:

  • pvs-studio - ядро анализатора;
  • pvs-studio-analyzer - утилита для проверки проектов без интеграции;
  • plog-converter - утилита для преобразования отчёта анализатора в различные форматы;

Установить анализатор можно следующими способами:

Установка из репозиториев

Для debian-based систем:

wget -q -O - https://files.viva64.com/etc/pubkey.txt | \
  sudo apt-key add -

sudo wget -O /etc/apt/sources.list.d/viva64.list \
  https://files.viva64.com/etc/viva64.list

sudo apt-get update
sudo apt-get install pvs-studio

Для yum-based систем:

wget -O /etc/yum.repos.d/viva64.repo \
  https://files.viva64.com/etc/viva64.repo

yum update
yum install pvs-studio

Для zypper-based систем:

wget -q -O /tmp/viva64.key https://files.viva64.com/etc/pubkey.txt
sudo rpm --import /tmp/viva64.key
sudo zypper ar -f https://files.viva64.com/rpm viva64
sudo zypper update
sudo zypper install pvs-studio

Ручная установка

Вы можете скачать PVS-Studio для Linux здесь.

Deb пакет

sudo gdebi pvs-studio-VERSION.deb

или

sudo dpkg -i pvs-studio-VERSION.deb
sudo apt-get -f install

Rpm пакет

sudo dnf install pvs-studio-VERSION.rpm

или

sudo zypper install pvs-studio-VERSION.rpm

или

sudo yum install pvs-studio-VERSION.rpm

или

sudo rpm -i pvs-studio-VERSION.rpm

Архив

tar -xzf pvs-studio-VERSION.tgz
sudo ./install.sh

Запуск анализатора

После успешной установки анализатора на ваш компьютер, для проверки проекта следуйте инструкциям на этой странице: "Как запустить PVS-Studio в Linux".

Установка и обновление PVS-Studio в macOS

PVS-Studio распространяется в виде графического инсталлятора, архива или через Homebrew репозиторий. Воспользовавшись установкой из репозитория, вы сможете получать обновления анализатора автоматически.

В дистрибутиве содержатся следующие файлы:

  • pvs-studio - ядро анализатора;
  • pvs-studio-analyzer - утилита для проверки проектов без интеграции;
  • plog-converter - утилита для преобразования отчёта анализатора в различные форматы;

Установить анализатор можно следующими способами:

Установка из Homebrew

Установка:

brew install viva64/pvs-studio/pvs-studio

Обновление:

brew upgrade pvs-studio

Ручная установка

Инсталлятор

Запуститите .pkg файл и следуйте инструкциям инсталлятора:

https://import.viva64.com/docx/manual/PVS-Studio_macOS_Package_ru/image1.png

Архив

Распакуйте архив и поместите исполняемые файлы в каталог, доступный в PATH.

tar -xzf pvs-studio-VERSION.tgz

Запуск анализатора

После успешной установки анализатора на ваш компьютер, для проверки проекта следуйте инструкциям на этой странице: "Как запустить PVS-Studio в Linux и macOS".

Массовое подавление сообщений анализатора (отключение выдачи предупреждений на существующий код)

Механизм подавления предупреждений анализатора подходит для следующих сценариев:

  • PVS-Studio впервые внедряется в проект и выдаёт большое количество предупреждений на весь код. Руководитель разработки решает начать регулярное использование анализатора только на новом коде, планируя вернуться к текущим предупреждениям позже;
  • PVS-Studio используется в проекте на регулярной основе. В процессе разработки в отчёте анализатора попадаются ложные предупреждения, и их хочется подавить без модификации файлов с исходным кодом.

В этих ситуациях предупреждения анализатора можно подавить специальным образом, чтобы они больше не попадали в новые отчёты. Использование этого режима не требует модификации файлов с исходным кодом проекта.

Анализатор поддерживает анализ исходного кода для языков программирования C, C++, C# и Java. Анализ может быть выполнен на операционных системах Windows, Linux и macOS. В связи с этим, способы подавления предупреждений могут отличаться в зависимости от используемой платформы и типа проектов, поэтому перейдите в раздел, который Вам подходит, и следуйте приведённой там инструкции.

Принцип работы

Механизм подавления сообщений основан на использовании специальных файлов, которые добавляются рядом с проектом (или в любом заданном месте). Такие файлы подавления содержат сообщения, размеченные для данного проекта как "ненужные". Заметим, что модификация исходного файла, содержащего размеченные сообщения, и, в частности, сдвиг строк, не приведёт к повторному появлению подавленных сообщений. Однако, правка строки, содержащей сообщение анализатора, может привести к его повторному появлению, т.к. такое сообщение уже считается "новым".

Windows: Visual Studio (анализ C, C++ и C#)

Для Microsoft Visual Studio доступен плагин PVS-Studio, удобно интегрированный в IDE. Он позволяет запускать анализ всего solution'а, конкретных проектов или отдельных файлов, а также поддерживает инкрементальный анализ.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image1.png

В меню PVS-Studio доступен пункт Suppress Messages, открывающий окно для работы с подавленными предупреждениями анализатора.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image2.png

В открывшемся окне доступно несколько действий:

  • Suppress All - подавление всех предупреждений анализатора;
  • Suppress Filtered - подавление сообщений, которые в данный момент отображены в окне результатов работы PVS-Studio, без учёта отфильтрованных сообщений;
  • Un-Suppress from Selected - восстановление скрытых предупреждений для выделенных проектов;
  • Display Suppressed Messages - отображение скрытых предупреждений анализатора в окне (PVS-Studio Output Window) с остальными предупреждениями. В этом режиме можно вернуться к исправлению подавленных ранее предупреждений. Такие сообщения будут помечены особым образом (зачёркнуты), поэтому их невозможно спутать с другими.

Для просмотра результатов анализа в Visual Studio существует специальное окно.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image4.png

Специальное окно позволяет выполнять навигацию по найденным предупреждениям и переходить к коду для его исправления. Окно PVS-Studio предоставляет широкие возможности фильтрации и сортировки результатов. Также присутствует возможность быстрого перехода к документации выбранной диагностики.

Дополнительные возможности работы с каждым сообщением доступны в контекстном меню по нажатию на правый клик мыши на сообщении.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image6.png

Здесь доступна команда для подавления выделенного предупреждения. При открытии меню на уже подавленном предупреждении будет доступен пункт для возвращения срабатывания.

Таким же образом вы можете и убрать отметку "подавленного сообщения", используя пункт контекстного меню 'Un-Suppress Selected Messages'. С выбранных сообщений будет снята отметка "подавленных", и они будут удалены из suppress файлов в случае, если в IDE открыт соответствующий им проект.

Добавление suppress файлов в MSBuild \ Visual Studio проекты

После создания suppress файла вы можете включить его в проект как некомпилируемый\текстовый файл с помощью команды меню 'Add|Existing Item...'. При наличии в проекте хотя бы одного suppress файла, файлы рядом с самим проектным файлом будут игнорироваться. Такое добавление позволяет держать suppress файлы и файлы проектов в разных директориях. Поддерживается добавление не более одного suppress файла на проект - остальные будут игнорироваться.

Добавление suppress файлов в Visual Studio solution

Вы можете добавить suppress файл в решение (solution). Сделать это можно с помощью команды меню 'Add|New Item...'. Как и для проектов, для решений поддерживается только один suppress файл - остальные будут игнорироваться.

Suppress файл уровня solution позволяет подавлять сообщения во всех проектах соответствующего solution. Если у проектов есть отдельные suppress файлы, анализатор будет учитывать как предупреждения, подавленные в suppress файле solution, так и в suppress файле проекта.

При подавлении предупреждений в случаях, когда suppress файл добавлен в solution, действуют следующие правила:

  • если suppress файл добавлен только в solution, предупреждения подавляется только в нём - suppress файлы уровня проекта не создаются;
  • если suppress файлы добавлены в solution и в проект, предупреждения будут подавлены в обоих файлах.

Подавление сообщений анализатора из командной строки

Механизм подавления сообщений можно также использовать напрямую из командной строки. Утилита командной строки PVS-Studio_Cmd.exe автоматически подхватывает существующие suppress файлы при проверке. Также её можно использовать для подавления ранее сгенерированных сообщений анализатора, сохранённых в plog файле. Для подавления сообщений из существующего plog файла необходимо запустить PVS-Studio_Cmd.exe с флагом '--suppressAll'. Например (в одну строку):

"C:\Program Files (x86)\PVS-Studio\PVS-Studio_Cmd.exe"
-t "Solution.sln" -o "results.plog" --suppressAll SuppressOnly

Исполнение команды сгенерирует suppress файлы для всех проектов, содержащихся в Solution.sln, на которые были сгенерированы сообщения в results.plog.

Флаг '--suppressAll' поддерживает 2 режима работы. SuppressOnly запустит подавление для переданного plog'а без перезапуска анализа. AnalyzeAndSuppress сначала выполнит анализ, запишет выходной plog файл, и только затем подавит все сообщения из него. Такой режим запуска позволит видеть только новые сообщения анализатора в каждом последующем запуске (т.к. сообщения с предыдущих запусков будут подавлены).

Windows: C and C++ Compiler Monitoring UI

PVS-Studio на Windows можно использовать не только для проверки MSBuild \ Visual Studio проектов. С помощью системы отслеживания вызовов компилятора, вы можете запустить статический анализ любых типов проектов, использующих один из поддерживаемых в PVS-Studio C++ компиляторов.

При запуске анализа, после мониторинга сборки, с помощью команды

clmonitor.exe analyze --useSuppressFile %PathToSuppressFile%

можно с помощью дополнительного флага --useSuppressFile (-u) передать анализатору путь до suppress файла, который будет использован при проверке.

Помимо консольного инструмента CLMonitor.exe, использовать мониторинг компиляции можно также и с помощью графической утилиты C and C++ Compiler Monitoring UI. Эта утилита предоставляет возможности для проверки кода, независимо от используемого компилятора или сборочной системы, а затем позволяет работать с результатами анализа, предоставляя пользовательский интерфейс, схожий с Visual Studio плагином PVS-Studio.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image7.png

Тем не менее, если у вас есть проект, который можно открыть в Visual Studio, мы рекомендуем вам, для просмотра результатов анализа использовать Visual Studio плагин PVS-Studio, т.к. возможности встроенного в Compiler Monitoring UI редактора кода значительно уступают редактору кода Visual Studio. Для этого вы можете сохранить отчёт анализатора и переоткрыть его в Visual Studio.

Меню для запуска анализа и подавления предупреждений выглядит следующим образом.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image9.png

При выборе пункта меню для запуска анализа появится окно "Compiler Monitoring (C and C++)".

https://import.viva64.com/docx/manual/MessageSuppression_ru/image10.png

Для фильтрации предупреждений анализатора, перед анализом необходимо указать файл с подавленными ранее предупреждениями. Создать и пополнять такой файл можно через меню "Message Suppression...", которое является таким же, как было представлено в разделе про Visual Studio на рисунке 2. После завершения анализа в окне PVS-Studio будут отображены только новые ошибки. Без указания файла анализатор выдаст все результаты.

Проекты на C и C++ в Linux/macOS

В Linux/macOS команды подавления и фильтрации сообщений анализатора выполняются только в консоли, при необходимости этот процесс может быть автоматизирован на сервере, выполняющем автоматический запуск анализа. Есть несколько способов использования этого механизма, в зависимости от варианта интеграции анализатора.

Подавление с помощью утилиты pvs-studio-analyzer

Для подавления всех предупреждений анализатора (первый раз и в последующих случаях) необходимо выполнять команду:

pvs-studio-analyzer suppress /path/to/report.log

Анализ проекта можно запускать как прежде. При этом подавленные предупреждения будут фильтроваться:

pvs-studio-analyzer analyze ... -o /path/to/report.log
plog-converter ...

При таком запуске подавленные предупреждения будут сохраняться в текущем каталоге, в файле с именем suppress_base.json, который надо хранить с проектом. Новые подавленные предупреждения будут дописываться в этот файл. Если необходимо указать другое имя или расположение файла, то команды выше можно дополнить, указав путь до файла с подавленными предупреждениями.

Прямая интеграция анализатора в сборочную систему

Прямая интеграция анализатора может выглядеть следующим образом:

.cpp.o:
  $(CXX) $(CFLAGS) $(DFLAGS) $(INCLUDES) $< -o $@
  pvs-studio --cfg $(CFG_PATH) --source-file $< --language C++
     --cl-params $(CFLAGS) $(DFLAGS) $(INCLUDES) $<

В этом режиме интеграции происходит вызов C++ ядра анализатора напрямую, поэтому анализатор не может одновременно проверять исходные файлы и фильтровать их. Поэтому для фильтрации и подавления предупреждений потребуется вызывать дополнительные команды.

Для подавления всех предупреждений анализатора необходимо выполнить команду:

pvs-studio-analyzer suppress /path/to/report.log

Для фильтрации нового лога по ранее сгенерированному файлу подавления, необходимо воспользоваться следующими командами:

pvs-studio-analyzer filter-suppressed /path/to/report.log
plog-converter ...

Файл с подавленными предупреждениями также имеет имя по умолчанию suppress_base.json, для которого при необходимости можно задать произвольное имя.

Проекты на Java в Windows/Linux/macOS

Подавление сообщений в IntelliJ IDEA

Для просмотра результатов анализа в IntelliJ IDEA существует специальное окно.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image11.png

Специальное окно позволяет выполнять навигацию по найденным предупреждениям и переходить к коду для его исправления. Окно PVS-Studio предоставляет широкие возможности фильтрации и сортировки результатов. Также присутствует возможность быстрого перехода к документации выбранной диагностики.

Дополнительные возможности работы с каждым сообщением доступны в контекстном меню по нажатию на правый клик мыши на сообщении. Здесь доступна команда для подавления выделенного предупреждения.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image12.png

В плагине PVS-Studio для IntelliJ IDEA есть механизм, который позволяет подавить сразу все сообщения одним нажатием кнопки:

https://import.viva64.com/docx/manual/MessageSuppression_ru/image13.png

По умолчанию файл подавления расположен по пути {projectPath}/.PVS-Studio/suppress_base.json, но в настройках плагина есть возможность изменить этот путь:

https://import.viva64.com/docx/manual/MessageSuppression_ru/image14.png

Какой бы способ подавления Вы не использовали, при следующем анализе подавленные Вами сообщения не попадут в отчет.

Подавление сообщений анализатора в Gradle

Для подавления предупреждений анализатора необходимо выполнять команду:

./gradlew pvsSuppress "-Ppvsstudio.report=/path/to/report.json"
  "-Ppvsstudio.output=/path/to/suppress_base.json"

Подавление сообщений анализатора в Maven

Для подавления предупреждений анализатора необходимо выполнять команду:

mvn pvsstudio:pvsSuppress "-Dpvsstudio.report=/path/to/report.json"
  "-Dpvsstudio.output=/path/to/suppress_base.json"

Прямая интеграция анализатора в сборочную систему

Для подавления предупреждений анализатора необходимо выполнять команду:

java -jar pvs-studio.jar --convert toSuppress
  --src-convert "/path/to/report.json"
  --dst-convert "/path/to/suppress_base.json"

Подавление предупреждений в SonarQube

SonarQube (бывший Sonar) — платформа с открытым исходным кодом для непрерывного анализа (англ. continuous inspection) и измерения качества кода.Пользователям этой системы доступен плагин для PVS-Studio. SonarQube сводит результаты анализа к единой информационной панели, ведя историю прогонов и позволяя тем самым увидеть общую тенденцию изменения качества программного обеспечения в ходе разработки. Дополнительным преимуществом является возможность объединять результаты разных анализаторов.

Так, получив результаты анализа одного или нескольких анализаторов, необходимо перейти к списку предупреждений и кликнуть на кнопку "Bulk Change", после чего откроется следующее меню.

https://import.viva64.com/docx/manual/MessageSuppression_ru/image15.png

В этом окне можно разметить все предупреждения анализатора как "won't fix" и в дальнейшем работать только с новыми ошибками.

Что делать после подавления всех предупреждений?

Настроить статический анализ на сборочном сервере и компьютерах разработчиков. В дальнейшем исправлять новые предупреждения анализатора и не давать им накапливаться. Также стоит запланировать поиск и исправление ошибок среди подавленных предупреждений.

Дополнительный контроль за качеством кода поможет обеспечить рассылка результатов по почте. Рассылать предупреждения только для тех разработчиков, которые внесли ошибочный код, возможно с помощью утилиты BlameNotifier, которая входит в Windows дистрибутив PVS-Studio.

Некоторым может быть удобно загружать результаты в Jenkins или TeamCity с помощью плагина PVS-Studio, и рассылать ссылку на эту страницу.

Дополнительные ссылки

На странице приведены все возможные способы подавления предупреждений анализатора на данный момент. Описание этого механизма основывается на документации к анализатору PVS-Studio, но детали по этой теме были рассмотрены подробнее. Общие сведения могут быть не очень информативны для новых пользователей, поэтому следует ознакомиться с документацией по ссылкам ниже.

Работа со списком диагностических сообщений

При работе с большим количеством сообщений (а при первичной проверке крупных проектов, когда ещё не настроены фильтры и не размечены ложные срабатывания, число сообщений может достигать десятков тысяч), разумно воспользоваться средствами навигации поиска, и фильтрации встроенными в окно вывода результатов PVS-Studio.

Навигация и сортировка

Окно вывода результатов PVS-Studio в первую очередь предназначено для упрощения навигации по коду анализируемого проекта и переходу к участкам кода, содержащим потенциальные ошибки. Двойной щелчок мыши по любому из сообщений в списке автоматически откроет в редакторе кода файл, на который данное сообщение указывает, переведёт курсор на интересующую строку и выделит её. Кнопки быстрой навигации (рисунок 1) позволяют легко просматривать обнаруженные потенциально опасные места в исходном коде без необходимости постоянно переключаться между окнами среды разработки.

https://import.viva64.com/docx/manual/Navigation_ru/image1.png

Рисунок 1 — Кнопки быстрого перехода

Для представления результатов анализа окно PVS-Studio использует виртуальную таблицу, позволяющую быстро отображать и осуществлять сортировку сгенерированных сообщений даже для очень крупных проектов (виртуальная таблица позволяет работать со списками из сотен тысяч строк без заметного ущерба для производительности). Крайний левый столбец таблицы предназначен для пометки интересных сообщений, например, тех, к которым имеет смысл вернуться повторно. Данный столбец также поддерживает сортировку, поэтому найти все сообщения, размеченные подобным образом, не составит труда. Пункт контекстного меню "Show Columns" позволяет настроить отображаемые в таблице столбцы (рисунок 2):

https://import.viva64.com/docx/manual/Navigation_ru/image2.png

Рисунок 2 — Настройка отображения таблицы вывода результатов

Таблица поддерживает множественное выделение с помощью стандартных комбинаций Ctrl и Shift, при этом выделение строк сохраняется и после пересортировки по любой другой колонке. Пункт меню "Copy selected messages to clipboard" (либо сочетание Ctrl+C) позволяет скопировать в буфер обмена содержимое всех выделенных в таблице строк.

Фильтрация сообщений

Механизмы фильтрации окна вывода PVS-Studio позволяют быстро найти и отобразить как отдельные диагностические сообщения, так целые их группы. Панель инструментов окна содержит ряд переключателей, позволяющих включить либо отключить отображение сообщений из соответствующих им групп сообщений (рисунок 3).

https://import.viva64.com/docx/manual/Navigation_ru/image3.png

Рисунок 3 — Группы фильтрации сообщений

Все переключатели можно разбить на 3 группы: фильтры по уровню диагностической достоверности сообщений, фильтры по принадлежности сообщения к определённому типу диагностических правил, фильтр размеченных в коде ложных срабатываний. Отключение этих фильтров мгновенно отключает отображение соответствующих им сообщений в списке.

Детальное описание уровней достоверности предупреждений и наборов диагностических правил приведено в разделе документации "Знакомство со статическим анализатором кода PVS-Studio".

Механизм быстрой фильтрации (quick filters) позволяет отфильтровать отчёт анализатора по заданным ключевым словам. Открыть панель быстрой фильтрации можно с помощью кнопки Quick Filters панели инструментов окна (рисунок 4).

https://import.viva64.com/docx/manual/Navigation_ru/image5.png

Рисунок 4 — Панель быстрой фильтрации

Быстрая фильтрация позволяет отобразить сообщения в соответствии с фильтрами по 3-м ключевым словам: по коду сообщения, по тексту сообщения и по файлу, содержащему данное сообщение. Например, отобразить все сообщения, содержащие слово 'odd' из файла 'command.cpp'. Изменения в списке сообщений становятся видны сразу после выхода из поля ввода ключевого слова (при потере фокуса). Кнопка Reset Filters очищает заданные в данный момент ключевые слова.

Все перечисленные механизмы фильтрации сообщений можно совмещать между собой, фильтруя, например, уровень отображаемых сообщений и файл, к которому сообщения должны относиться, исключая сообщения, помеченные как ложные срабатывания.

Быстрый переход к отдельным сообщениям

При необходимости перехода на какое-либо конкретное сообщение в таблице можно воспользоваться диалогом быстрого перехода к строке, который вызывается через пункт контекстного меню "Navigate to ID..."(рисунок 5):

https://import.viva64.com/docx/manual/Navigation_ru/image7.png

Рисунок 5 - Вызов диалога быстрого перехода

https://import.viva64.com/docx/manual/Navigation_ru/image8.png

Рисунок 6 - Диалог быстрого перехода к сообщению

Каждое сообщение в списке вывода PVS-Studio имеет уникальный идентификатор — порядковый номер добавления этого сообщения в таблицу, который отображён в колонке ID. Диалог быстрого перехода позволяет выделить и автоматически сфокусировать сообщение с заданным идентификатором ID, независимо от текущей сортировки таблицы и выделенных строк. Обратите внимание, что ID идентификаторы отображённых в таблице сообщений не всегда идут последовательно, т.к. часть сообщений может быть скрыта с помощью механизмов фильтрации. Переход к таким сообщениям невозможен.

Организация работы с помощью Visual Studio Task List

Зачастую в разработке крупных проектов принимают участие распределённые группы разработчиков, а поэтому очень часто один человек не имеет возможности оценить каждое из сообщений статического анализатора на предмет ложно-позитивного срабатывания и, тем более, внести исправления в соответствующий участок исходного кода. В такой ситуации имеет смысл делегировать рассмотрение подобного сообщения разработчику, непосредственно отвечающему за данный участок.

PVS-Studio позволяет автоматически сгенерировать и внести в код комментарий TODO специального вида, содержащий всю необходимую информацию для оценки и анализа отмеченного им фрагмента программы. Такой комментарий будет сразу отображён в окне задач Visual Studio (окно Task List, для версии Visual Studio 2010 необходимо включить разбор комментариев в настройках Tools->Options->Text Editor->C++->Formatting->Enumerate Comment Tasks->true) при условии, что в настройках Tools->Options->Environment->Task List->Tokens задана соответствующая TODO лексема (присутствует в настройках по умолчанию). Комментарий может быть добавлен с помощью команды контекстного меню 'Add TODO comments for selected messages' (рисунок 7)

https://import.viva64.com/docx/manual/Navigation_ru/image9.png

Рисунок 7 - Вставка TODO комментария

TODO комментарий будет вставлен в строку, сгенерировавшую сообщение анализатора, и будет содержать код ошибки, текст сообщения анализатора и ссылку на online документацию для данного типа ошибок. Благодаря окну заданий (Task List) данный комментарий может быть легко найден любым имеющим доступ к исходному коду разработчиком, а сам текст комментария позволит выявить и исправить потенциальную ошибку даже в случае отсутствия у программиста установленной версии PVS-Studio или полного отчёта о работе анализатора (рисунок 8).

https://import.viva64.com/docx/manual/Navigation_ru/image10.png

Рисунок 8 - Окно заданий Visual Studio

В Visual Studio открыть окно Task List можно через меню View->Other Windows->Task List. Комментарии TODO отображаются в разделе Comments окна.

Подавление ложных предупреждений

В данном разделе описаны механизмы подавления предупреждений, выдаваемых анализатором. С помощью описанных здесь механизмов можно управлять как отдельными сообщениями, выдаваемыми на определённые строки кода, так и подавлять множественные срабатывания, возникающие, например, из-за использования C/C++ макросов. Описан способ, как с помощью комментариев указать анализатору выключить то или иное сообщение анализатора или изменить выдаваемый текст сообщения.

Механизмы, описанные в данном разделе, применимы как для C/C++, так и для C# анализаторов PVS-Studio, если явно не указано обратное.

Механизм подавления отдельных ложных срабатываний (Mark as False Alarm)

Любой анализатор кода всегда выдает помимо полезных сообщений об ошибках еще множество так называемых "ложных срабатываний". Это ситуации, когда программисту совершенно очевидно, что в коде нет ошибки, а анализатору это не очевидно. Такие ложные срабатывания называют False Alarm. Рассмотрим пример кода:

obj.specialFunc(obj);

Анализатор считает подозрительным, что у объекта вызывается метод, в качестве аргумента в который передаётся тот же самый объект, поэтому он выдаст на данный код предупреждение V678. Программист же может знать, что использование метода 'specialFunc' таким образом вполне допустимо, поэтому предупреждение анализатора в данном случае является ложным срабатыванием. О том, что предупреждение V678, выданное на этот код, является ложным, можно сообщить анализатору. Это можно сделать либо вручную, либо с помощью команды контекстного меню.

Чтобы подавить ложное срабатывание, в код можно добавить специальный комментарий:

obj.specialFunc(obj); //-V678

Теперь анализатор не будет выдавать предупреждение V678 на эту строку. После того, как сообщение будет отмечено как ложное срабатывание, оно исчезнет из списка. Для включения отображения размеченных подобным образом сообщений можно воспользоваться настройкой 'PVS-Studio -> Options... -> Specific Analyzer Settings -> DisplayFalseAlarms'

Комментарий, подавляющий предупреждения, можно вписать в код самостоятельно, но важно полностью соблюдать формат записи: две косые черты, минус (без пробела), код ошибки. Также можно воспользоваться специальной командной для этого, предоставляемой PVS-Studio. Пользователю предоставляется две команды, доступные из контекстного меню PVS-Studio (рисунок 1).

https://import.viva64.com/docx/manual/SuppressionFalseAlarm_ru/image1.png

Рисунок 1 - Команды для работы с механизмом подавления ложных предупреждений

Рассмотрим доступные команды, относящиеся к подавлению ложных предупреждений:

1. Mark selected messages as False Alarms. Вы можете выбрать одно или несколько предупреждений в списке (рисунок 2) и воспользоваться этой командой для разметки соответствующего кода, как безопасного.

https://import.viva64.com/docx/manual/SuppressionFalseAlarm_ru/image2.png

Рисунок 2 - Выбор предупреждений перед выполнением команды "Mark selected messages as False Alarms"

2. Remove False Alarm marks from selected messages. Убирает комментарий, помечающий код как безопасный. Функция, например, может быть полезна, если вы поспешили и ошибочно отметили код как безопасный. Как и в предыдущем случае, вы должны выбрать сообщения из списка, которые планируете обработать.

Не рекомендуется использовать разметку сообщений как ложных предупреждений без предварительного просмотра соответствующего кода, так как это противоречит идеологии статического анализа. Только программист может определить, является ли сообщение об ошибке ложным.

Реализация функции подавления ложных предупреждений

Обычно в компиляторах для подавления отдельных сообщений об ошибках используют #pragma-директивы. Приведем пример кода:

unsigned arraySize = n * sizeof(float);

Компилятор выдает сообщение:

warning C4267: 'initializing' : conversion from 'size_t' to 'unsigned

int', possible loss of data x64Sample.cpp 151

Это сообщение можно подавить с помощью следующей конструкции:

#pragma warning (disable:4267)

Точнее, чтобы подавить конкретно это сообщение, лучше оформить код так:

#pragma warning(push)
#pragma warning (disable:4267) 
  unsigned arraySize = n * sizeof(float);
#pragma warning(pop)

Анализатор PVS-Studio в качестве разметки использует комментарии специального вида. Для той же строчки кода подавление сообщения PVS-Studio будет выглядеть так:

unsigned arraySize = n * sizeof(INT_PTR); //-V103

Такой подход был выбран для повышения наглядности конечного кода. Дело в том, что PVS-Studio может сообщать о проблемах в середине многострочных выражений, как, например, здесь:

  size_t n = 100;
  for (unsigned i = 0;
       i < n; // анализатор сообщит о проблеме здесь
       i++)
  {
      // ...
  }

Чтобы подавить это сообщение при использовании комментария, достаточно написать:

  size_t n = 100;
  for (unsigned i = 0;
       i < n; //-V104
       i++)
  {
      // ...
  }

Если же в это выражение пришлось бы добавлять #pragma-директиву, то код выглядел бы значительно менее наглядно.

Хранение разметки в исходном коде позволяет вносить в него модификации без опасения потерять информацию о строках с ошибками.

Можно также использовать отдельную базу, в которой хранить информацию примерно так: код ошибки, имя файла, номер строки. Данный подход отдельно реализован в PVS-Studio и называется "Mass Suppression".

Подавление ложных предупреждений в С/С++ макросах (#define) и для других фрагментов кода

В макросах (#define) анализатор также, разумеется, может находить потенциальные проблемы и выдавать на них диагностические сообщения. Но при этом анализатор будет выдавать сообщения в тех местах, где макрос используется, то есть где фактически происходит подстановка тела макроса в код. Пример:

#define TEST_MACRO \
  int a = 0;       \
  size_t b = 0;    \
  b = a; 

void func1()
{
  TEST_MACRO // V1001 here
}

void func2()
{
  TEST_MACRO // V1001 here
}

Чтобы подавить это сообщение, можно использовать команду "Mark as False Alarm". Тогда код с расставленными командами подавления будет выглядеть так:

#define TEST_MACRO \
  int a = 0;       \
  size_t b = 0;    \
  b = a; 

void func1()
{
  TEST_MACRO //-V1001
}

void func2()
{
  TEST_MACRO //-V1001
}

Однако, если макрос используется очень активно, то везде размечать его как False Alarm не очень удобно. Есть возможность в коде сделать вручную специальную пометку, чтобы анализатор автоматически размечал диагностики в этом макросе как False Alarm. С этой пометкой код будет выглядеть так:

//-V:TEST_MACRO:1001

#define TEST_MACRO \
  int a = 0;       \
  size_t b = 0;    \
  b = a; 

void func1()
{
  TEST_MACRO
}

void func2()
{
  TEST_MACRO
}

При проверке такого кода сообщения о проблемах в макросе уже сразу будут помечены как False Alarm. Причем можно указывать несколько диагностик сразу, через запятую:

//-V:TEST_MACRO:1001, 105, 201

Обратите внимание, что если макрос содержит вложенные макросы, то для автоматической пометки нужно указывать все равно имя макроса самого верхнего уровня:

#define NO_ERROR 0
#define VB_NODATA ((long)(77))
size_t stat;

#define CHECK_ERROR_STAT                        \
    if( stat != NO_ERROR &&  stat != VB_NODATA ) \
      return stat;

size_t testFunc()
{
    {
      CHECK_ERROR_STAT // #1
    }

    {
      CHECK_ERROR_STAT // #2
    }

    return VB_NODATA; // #3
}

В указанном примере диагностика V126 появляется в трех местах. Чтобы автоматически помечать ее как False Alarm в местах #1 и #2 нужно добавить такой код:

//-V:CHECK_ERROR_STAT:126

А чтобы и в #3 это сработало, необходимо указать еще:

//-V:VB_NODATA:126

К сожалению, просто указать "сразу помечать V126 в макросе VB_NODATA" и не указывать про макрос CHECK_ERROR_STAT нельзя из-за технических особенностей механизма препроцессирования.

Всё написанное в этом разделе про макросы справедливо также и для любого фрагмента кода. То есть если, например, вы хотите подавить все срабатывания диагностики V103 на вызов функции 'MyFunction', необходимо добавить такую строку:

//-V:MyFunction:103

Подавление ложных предупреждений с помощью файлов конфигурации диагностик (.pvsconfig)

Отображением и фильтрацией сообщений можно управлять с помощью комментариев специального вида. Такие комментарии можно писать в специальных файлах конфигурации (.pvsconfig) для всех анализаторов, либо непосредственно в коде проекта (только для C/C++ анализатора).

Файлы конфигурации диагностик анализатора представляют собой простые текстовые файлы, добавляемые в Visual Studio проект либо solution. Для добавления файла конфигурации, выделите интересующий вас проект или solution в окне Solution Explorer среды Visual Studio и выберите пункт контекстного меню 'Add New Item...'. В появившемся окне выберите тип файла 'PVS-Studio Filters File' (рисунок 3):

https://import.viva64.com/docx/manual/SuppressionFalseAlarm_ru/image4.png

Рисунок 3 - Добавление в solution файла конфигурации диагностик анализатора.

Из-за особенностей некоторых версий среды Visual Studio, тип файлов 'PVS-Studio Filters File' может отсутствовать на некоторых версиях и редакциях Visual Studio в окне добавления нового файла для solution и\или проекта. В таком случае, можно добавить в проект обычный текстовый файл, задав ему расширение 'pvsconfig'. В свойствах этого файла (после добавления), должно быть указано, что файл не участвует в сборке.

Файл конфигурации, добавленный в проект, действует на все файлы данного проекта. Файл конфигурации, добавленный в solution, действует на все файлы всех проектов, добавленных в данный solution.

Также можно разместить файл конфигурации .pvsconfig в текущей папке пользовательских данных (%AppData%\PVS-Studio\) - такой файл будет подхвачен автоматически при запуске проверки, без необходимости как-либо модифицировать проектные файлы.

При использовании инструмента командной строки PVS-Studio_Cmd указать путь к файлу конфигурации .pvsconfig можно через параметр --rulesConfig (-C), например:

PVS-Studio_Cmd.exe -t D:\project\project.sln 
-C D:\project\rules.pvsconfig

Файлы конфигурации диагностик .pvsconfig имеют простой синтаксис. Любая строка, начинающаяся с символа '#' считается комментарием и игнорируется. Фильтры записываются в формате однострочных C++/C# комментариев, т.е. должны начинаться с символов '//'.

Для C/C++ кода, фильтры также могут быть записаны в виде комментариев непосредственно в исходном коде. Обратите внимание, что такой формат записи не поддерживается в C# проектах!

Далее рассмотрим различные варианты фильтров, допустимых в файлах конфигурации диагностик.

Фильтрация сообщений по фрагменту исходного кода (например, имена макросов, переменных и функций)

Предположим, есть следующая структура:

struct MYRGBA
{
  unsigned data;
};

И ряд функций, которые её используют:

void f1(const struct MYRGBA aaa)
{
}

long int f2(int b, const struct MYRGBA aaa)
{
  return int();
}

long int f3(float b, const struct MYRGBA aaa,  char c)
{
  return int();
}

На все эти функции анализатор выдаст три сообщения V801: Decreased performance. It is better to redefine the N function argument as a reference. Сообщение в подобном коде будет ложным, так как компилятор сам оптимизирует код, и проблемы не будет.

Можно, конечно, каждое сообщение пометить как False Alarm с помощью функции Mark As False Alarm. Однако, есть способ лучше. Достаточно добавить в код строку:

//-V:MYRGBA:801

Для C/C++ проектов, мы рекомендуем добавлять такую строку в .h-файл рядом с объявлением структуры, но если это невозможно (например, структура в системном .h-файле), то можно прописать это в stdafx.h.

И тогда, после перепроверки, все три сообщения V801 будут автоматически помечены как False Alarm.

Описанный механизм может применяться для подавления предупреждений не только для отдельных слов. Иногда, это очень удобно.

Рассмотрим несколько примеров:

//-V:<<:128

Подавит предупреждения V128 в строках, где имеется оператор <<.

buf << my_vector.size();

Если вы хотите подавлять предупреждение V128 только при записи данных в объект с именем 'log', то можно написать так:

//-V:log<<:128
buf << my_vector.size(); // Есть предупреждение
log << my_vector.size(); // Нет предупреждения

Примечание. Обратите внимание, что строка для поиска не должна содержать пробелов.

Правильно: //-V:log<<:128
Неправильно: //-V:log <<:128

При поиске подстроки пробелы игнорируются. Но не беспокойтесь, следующая ситуация обработается корректно:

//-V:ABC:501
AB C = x == x; // Есть предупреждение
AB y = ABC == ABC; // Нет предупреждения

Полное отключение предупреждений

Существует возможность с помощью комментария полностью выключить предупреждение. В этом случае после двух двоеточий указывается номер отключаемой диагностики. Синтаксис:

//-V::(number) - для отключения одной диагностики

Для отключения нескольких диагностик можно перечислить их номера через запятую. Синтаксис:

//-V::(number1),(number2),...,(numberN) - для отключения сразу нескольких диагностик

Для отключения всех диагностик C++ или C# анализатора следует использовать следующую форму:

//-V::C++ или //-V::C#

Если требуется проигнорировать предупреждение V122, то можно указать в начале файла:

//-V::122

Если требуется, например, игнорировать предупреждения V502, V502 и V525, то в начале файла можно указать:

//-V::502,507,525

Поскольку анализатор не будет выдавать указанные предупреждения, то это может значительно уменьшить размер лога проверки, если какая-то диагностика даёт слишком много ложных срабатываний.

Исключение из анализа файлов по маскам

В случае необходимости можно задать исключение из анализа файлов / директорий, которые попадают под заданные маски. Это может быть удобно, например, для исключения из анализа кода сторонних библиотек или автоматически сгенерированных файлов.

Несколько примеров масок:

//V_EXCLUDE_PATH C:\TheBestProject\thirdParty
//V_EXCLUDE_PATH *\UE4\Engine\*
//V_EXCLUDE_PATH *.autogen.cs

Синтаксис масок идентичен синтаксису для опций 'FileNameMasks' и 'PathMasks', описанному в документе "Настройки: Don't Check Files".

Другие способы фильтрации сообщений в анализаторе PVS-Studio (Detectable Errors, Don't Check Files, Keyword Message Filtering)

Возможны ситуации, в которых определённый тип диагностик не актуален для анализируемого проекта, или какая-либо из диагностик анализатора выдаёт предупреждения на код, в корректности которого вы уверены. В таком случае можно воспользоваться системой группового подавления сообщений, основанной на фильтрации полученных результатов анализа. Список доступных режимов фильтрации можно открыть через общее меню PVS-Studio -> Options.

Следует отметить, что применение фильтров для группового подавления ложных срабатываний не требует перезапуска анализа, результаты фильтрации будут сразу отображены в окне вывода PVS-Studio.

Во-первых, можно отключить диагностику тех или иных ошибок по их коду. Это делается с помощью вкладки "Настройки: Detectable Errors". На вкладке обнаруживаемых ошибок можно указать номера ошибок, которые не надо показывать в отчете по анализу. Иногда бывает целесообразно убрать в отчете ошибки с определенными кодами. Например, если вы уверены, что ошибки, связанные с явным приведением типа (коды V201, V202, V203), вас не интересуют, то вы можете скрыть их показ. Также отображение ошибок определённого типа можно отключить с использованием команды контекстного меню "Hide all Vxxx errors". Соответственно, в случае, если необходимо включить отображение обратно, настроить это можно на упоминавшейся выше вкладке "Detectable Errors".

Во-вторых, можно отключить анализ некоторых частей проекта (некоторых папок или файлов проекта). Раздел "Настройки: Don't Check Files". На этой вкладке можно ввести информацию о библиотеках, включения (через директиву #include) из файлов которых анализировать не надо. Это может потребоваться для уменьшения количества лишних диагностических сообщений. Например, в проекте используется библиотека Boost. И хотя на какой-то код из этой библиотеки анализатор выдает диагностические сообщения, вы считаете, что эта библиотека является достаточно надежной и написана хорошо. Поэтому, возможно, не имеет смысла получать диагностические сообщения по поводу кода в этой библиотеке. В этом случае можно отключить анализ файлов из этой библиотеки, указав путь к ней на странице настроек. Кроме того, возможно ввести файловые маски для исключения некоторых файлов из анализа. Анализатор не будет проверять файлы, удовлетворяющие условиям маски. Например, подобным образом можно исключить из анализа автогенерируемые файлы.

Маски путей для файлов, сообщения из которых попали в текущий сгенерированный отчёт, можно автоматически добавить в список Don't Check Files с помощью команды контекстного меню "Don't check files and hide all messages from..." для выделенного в окне PVS-Studio Output сообщения (рисунок 4).

https://import.viva64.com/docx/manual/SuppressionFalseAlarm_ru/image6.png

Рисунок 4 — Добавление масок путей через контекстное меню

Данная команда позволит добавить в фильтры исключений как отдельный выбранный файл, так и маску по целой директории, в которой данный файл находится.

В-третьих, можно подавлять отдельные сообщения по тексту. На вкладке "Настройки: Keyword Message Filtering" можно настроить фильтрацию ошибок по содержащемуся в них тексту, а не по коду. При необходимости можно скрыть из отчета сообщения о диагностированных ошибках, содержащих определенные слова или фразы. Например, если в отчете есть ошибки, в которых указаны названия функций printf и scanf, а вы считаете, что ошибок, связанных с ними, быть не может, то просто добавьте эти два слова с помощью редактора подавляемых сообщений.

Массовое подавление сообщений анализатора (Mass Suppression)

Иногда, особенно на стадии внедрения статического анализа в крупных проектах, может возникнуть необходимость 'подавить' все предупреждения анализатора на имеющуюся кодовую базу, т.к. разработчики могут не иметь необходимых ресурсов для исправления найденных анализатором ошибок в старом коде. В таком случае может быть полезно 'скрыть' все предупреждения, выданные на имеющийся код, чтобы отслеживать только вновь появляющиеся ошибки. Этого можно достичь за счёт использования механизма "массового подавления сообщений анализатора". Использование соответствующего механизма в среде Windows описано в документе "Массовое подавление сообщений анализатора", в среде Linux – в соответствующем разделе документа "Как запустить PVS-Studio в Linux".

Возможные проблемы

В редких случаях автоматически расставленные разметки могут быть поставлены не в том месте, где должны быть. И тогда анализатор вновь выдаст эти же сообщения об ошибках, так как маркер не будет найден. Это проблема препроцессора, связанная с многострочными #pragma-директивами определенного типа, из-за которых также сбивается нумерация строк. Решением проблемы является пометка сообщений, на которых заметен сбой, вручную. PVS-Studio всегда сообщает о подобных ошибках сообщением "V002. Some diagnostic messages may contain incorrect line number".

Как и с любой другой процедурой, включающей в себя массовую обработку файлов, при использовании разметки сообщений как ложных стоит помнить о потенциально возможных конфликтах доступа. Так как во время разметки файлов один из файлов может быть открыт во внешнем редакторе и там модифицирован, результат совместной работы с файлом предсказать невозможно. Поэтому мы рекомендуем либо иметь копию исходного кода, либо пользоваться системами контроля версий.

Конвертация результатов анализа (утилита PlogConverter)

В данном разделе рассматривается конвертация логов для Windows. Конвертация логов в Linux и macOS описана в документе "Как запустить PVS-Studio в Linux и macOS".

Результатом проверки проекта с помощью PVS-Studio (плагин Visual Studio, или же в режиме из консоли) обычно является XML файл отчета анализатора (".plog"). При использовании прямой интеграции анализатора в сборочную систему, результатом работы является необработанный вывод C++ анализатора. Такие файлы можно просматривать через плагин PVS-Studio для Visual Studio, либо через приложение C and C++ Compiler Monitoring UI. Эти форматы отчёта, однако, не удобны, например, для прямого просмотра в текстовом редакторе, рассылки по электронной почте и т.п. В состав дистрибутива PVS-Studio среди прочего входит утилита PlogConverter, позволяющая преобразовывать результаты анализа в другие форматы.

Утилита PlogConverter

Открыв отчет с помощью текстового редактора, пользователь столкнется с XML-разметкой или нечитаемым "сырым" выводом анализатора. Для наглядного представления результатов анализа можно воспользоваться утилитой PlogConverter, поставляемой в дистрибутиве PVS-Studio. Утилиту PlogConverter можно найти в установочной директории PVS-Studio (по умолчанию это путь "C:\Program Files (x86)\PVS-Studio"). Вы также можете скачать исходный код утилиты.

Параметры утилиты

Флаг "--help" выведет основную информацию об утилите:

PlogConverter.exe --help

Рассмотрим детально каждый параметр утилиты:

  • --renderTypes (или -t): задает возможные варианты конвертации отчета. Поддерживаемыми форматами являются Html, FullHtml, Totals, Txt, Csv, Tasks, Plog, TeamCity. Если задан неявно, то отчет конвертируется во все форматы
    • Html: конвертирует сообщения анализатора в html-файл (удобно использовать в автоматических рассылках на email).
    • FullHtml: конвертирует сообщения анализатора и исходные файлы в html-файлы (можно просматривать отчёт анализатора в браузере с сортировкой по сообщениям и навигацией по коду).
    • Txt: конвертирует сообщения анализатора в текстовый файл.
    • Csv: конвертирует сообщения анализатора в формат файла с разделителями (удобно читаем, например, в Microsoft Excel).
    • Totals: выводит суммарную информацию о количестве предупреждений разных типов (GA, OP, 64, CS, MISRA) и разных уровней достоверности. Детальное описание уровней достоверности предупреждений и наборов диагностических правил приведено в разделе документации "Знакомство со статическим анализатором кода PVS-Studio".
    • Tasks: конвертирует сообщения анализатора в формат файла для просмотра в QtCreator.
    • Plog: позволяет соединить несколько xml отчетов в один или преобразовать необработанный вывод анализатора в xml лог.
    • TeamCity: конвертирует сообщения анализатора в файл, предназначенный для загрузки и просмотра в TeamCity CI.

Возможна комбинация разных форматов через "," (без пробелов), например:

PlogConverter.exe D:\Projct\results.plog --renderTypes=Html,Csv,Totals

или

PlogConverter.exe D:\Projct\results.plog -t Html,Csv,Totals
  • --analyzer (или -a): производит фильтрацию предупреждений согласно маске. Маска фильтрации имеет следующий вид:
MessageType:MessageLevels

"MessageType" может принимать один из следующих типов: GA, OP, 64, CS, MISRA, Fail

"MessageLevels" может принимать значения от 1 до 3

Возможна комбинация разных масок через ";" (без пробелов), например (одной строкой):

PlogConverter.exe D:\Projct\results.plog --renderTypes=Html,Csv,Totals
--analyzer=GA:1,2;64:1

или

PlogConverter.exe D:\Projct\results.plog -t Html,Csv,Totals -a GA:1,2;64:1

Запись соответствует следующей логике: сконвертировать ".plog" в Html, Csv, Totals отчеты, оставив только предупреждения общего назначения (GA) 1-ого и 2-ого уровней и 64-битные ошибки (64) 1-ого уровня.

  • --excludedCodes (или -d): задает список предупреждений (через ","), которые не следует включать в результирующий отчет. Например, нужно убрать предупреждения V101, V102, V200 (одной строкой):
PlogConverter.exe D:\Projct\results.plog --renderTypes=Html,Csv,Totals
--excludedCodes=V101,V102,V200

или

PlogConverter.exe D:\Projct\results.plog -t Html,Csv,Totals -d V101,V102,V200
  • --settings (или -s): задает путь к файлу конфигурации PVS-Studio. PlogConverter прочитает настройки отключенных предупреждений из переданного файла настроек, указанных в конфигурации. По сути, этот параметр расширяет список отключаемых предупреждений параметра "--excludedCodes".
  • --srcRoot (или -r): задает замену "SourceTreeRoot" маркера. Если при проверке путь до корневого каталога проекта был заменен на "SourceTreeRoot" маркер (|?|), то этот параметр становится обязательным (иначе файлы проекта не будут найдены).
  • --outputDir (или -o): задает директорию, куда будут сохранены конвертированные отчеты. Если параметр не задан, то файлы записываются рядом с "PlogConverter.exe".
  • --outputNameTemplate (или -n): задает шаблонное имя файла без расширения. Все конвертированные отчеты будут иметь одно и то же имя, но с разными расширениями (в зависимости от "--renderTypes", это могут быть ".txt", ".html", ".csv", ".tasks", ".plog").
  • --errorCodeMapping (или -m): включить отображение CWE ID и MISRA ID для найденных предупреждений: " -m cwe,misra".
  • --indicate-warnings (или -w): устанавливает возвращаемый код утилиты PlogConverter равный '2', если после фильтрации лога в отфильтрованном выходном файле (файлах) остались предупреждения.

Коды возврата

Утилита PlogConverter имеет несколько ненулевых кодов возврата, которые не означают проблемы в работе самой утилиты, т.е. даже если утилита вернула не '0', это ещё не означает, что она отработала с ошибкой. Приведём описание всех возможных кодов возврата, которые может вернуть PlogConverter.

  • '0' - конвертация отчёта прошла успешно;
  • '1' - при генерации одного из выходных файлов возникла ошибка;
  • '2' - выходной отчёт содержит неотфильтрованные или неподавленные предупреждения. Чтобы PlogConverter завершал свою работу кодом 2 при условии, что в выходном файле остались неотфильтрованные предупреждения, необходимо передавать утилите флаг --indicate-warnings (-w);
  • '3' - общая (неспецифичная) ошибка при работе утилиты, перехваченное исключение при работе. Обычно это сигнализирует о наличии ошибки в коде самого PlogConverter'а;
  • '4' - утилите были переданы неверные аргументы командной строки, или один из файлов, переданный как аргумент, не был найден или не существует.

Автоматическое оповещение о предупреждениях анализатора

В составе дистрибутива PVS-Studio поставляется утилита BlameNotifier, которая позволяет оповещать разработчиков, заложивших в репозиторий код, на который анализатор выдал предупреждения. Также возможна настройка оповещения обо всех обнаруженных предупреждениях определённого круга лиц (это может быть полезно, например, менеджерам и руководителям команд).

Более подробно данная утилита описана в соответствующем разделе документации: "Оповещение команд разработчиков (утилита blame-notifier)".

Примечание. Утилита BlameNotifier доступна только при наличии Enterprise лицензии. Для получения лицензии, пожалуйста, напишите нам.

Использование относительных путей в файлах отчётов PVS-Studio

По умолчанию, при генерации диагностических сообщений, PVS-Studio выдаёт абсолютные, полные пути до файлов, в которых анализатор нашёл ошибки. Поэтому при сохранении отчёта именно эти полные пути и попадут в результирующий файл (XML plog файл). В дальнейшем это может вызывать неудобства, например, при необходимости работы с таким файлом отчёта на машине, отличной от той, на которой отчёт был сгенерирован. Ведь пути до файлов с исходным кодом на двух машинах могут и различаться. А это приведёт к невозможности открывать файлы и использовать встроенный механизм навигации по коду в таком лог-файле.

Хотя решить данную проблему можно и ручной правкой путей в XML отчёте, гораздо удобнее сразу получать от анализатора сообщения с путями, записанными относительно какой-нибудь фиксированной директории (например, корневой директории дерева исходников проекта). Такой порядок работы позволяет получить файл отчёта с корректными путями и на любой другой машине путём простой замены "корня", относительно которого раскрываются все пути в файле отчёта PVS-Studio. PVS-Studio может автоматически производить такую генерацию относительных путей и подмену их "корня" с помощью настройки 'SourceTreeRoot' на странице "PVS-Studio -> Options -> Specific Analyzer Settings".

Приведём пример использования данного режима работы. По умолчанию поле настроек 'SourceTreeRoot' пусто, а анализатор всегда генерирует полные пути в выдаваемых диагностических сообщениях. Предположим, что проверяемый проект расположен в директории "C:\MyProjects\Project1". В нашем примере в качестве "корня" дерева исходников проекта можно взять путь "C:\MyProjects\", запишем этот путь в поле 'SourceTreeRoot' и запустим анализ.

По завершению анализа PVS-Studio автоматически заменит заданную нами корневую директорию исходников на специальный маркер, т.е. в сообщении на файл "C:\MyProjects\Project1\main.cpp", путь до данного файла будет передан, как "|?|Project1\main.cpp." Сообщения же на файлы, лежащие вне заданной корневой директории, затронуты не будут. Т.е. сообщение на файл из директории "C:\MyCommonLib\lib1.cpp" будет содержать абсолютный, полный путь до данного файла.

В дальнейшем, при работе с таким фалом отчёта через IDE плагин PVS-Studio, маркер |?| будет автоматически заменяться на значение настройки 'SourceTreeRoot', например, при использовании False Alarm разметки или навигации по сообщениям. Если же будет необходимо работать с данным файлом отчёта на другой машине, достаточно лишь указать в настройках IDE плагина новый путь до корня дерева исходников, например, "C:\Users\User\Projects\", и плагин будет автоматически осуществлять корректное раскрытие полных путей.

Данный режим можно также использовать и в Independent режиме анализатора, при прямой его интеграции в сборочную систему (make, msbuild и т.п.). Это позволяет распределить процесс полного анализа исходников и дальнейшую работу с результатами анализа, что может быть особенно полезно на крупном проекте. Например, проект может быть полностью проверен один раз на сборочном сервере, а с результатами проверки уже может работать сразу несколько разработчиков на своих локальных машинах.

Вы также можете использовать настройку 'UseSolutionDirAsSourceTreeRoot', представленную на той же странице. Данная настройка включает или выключает режим использования пути до папки, содержащей файл решения *.sln, в качестве параметра 'SourceTreeRoot'. При включении этого режима (True) в поле 'SourceTreeRoot' будет отображено значение '<Using solution path>'. При этом фактическое значение параметра 'SourceTreeRoot', сохраненное в файле настроек, не меняется. При выключении настройки 'UseSolutionDirAsSourceTreeRoot' (False) это значение (если ранее оно было задано) будет вновь отображено в поле 'SourceTreeRoot'. Таким образом, настройка 'UseSolutionDirAsSourceTreeRoot' просто меняет механизм генерации пути до файла, позволяя использовать в качестве параметра 'SourceTreeRoot' либо указанное пользователем значение, либо путь до папки, содержащей файл решения.

Просмотр результатов анализа в приложении C and C++ Compiler Monitoring UI

Введение

PVS-Studio можно использовать независимо от интегрированной среды разработки Visual Studio. Ядро анализатора представляет собой command-line утилиту, позволяющую проверять C/C++ файлы, компилируемые с помощью Visual C++, GCC или Clang. Поэтому мы разработали отдельное приложение, которое представляет оболочку для command-line утилиты и помогает работать с полученным логом сообщений.

PVS-Studio предоставляет удобное расширение среды Visual Studio, позволяющее "в один клик" проверять vcproj/vcxproj-проекты этой IDE. Однако существуют и другие сборочные системы, которые желательно поддержать. Хотя ядро PVS-Studio не зависит от конкретного формата, используемого той или иной сборочной системой (как например MSBuild, GNU Make, NMake, CMake, ninja и т.п.), для интеграции статического анализа PVS-Studio в систему сборки, отличную от поддерживаемых средой Visual Studio проектов VCBuild/MSBuild, от пользователя потребуется самостоятельно выполнить ряд действий. Перечислим их:

  • Во-первых, потребуется встроить вызов анализатора PVS-Studio.exe непосредственно в сборочный сценарий (при его наличии) конкретной системы. Либо потребуется модифицировать саму сборочную систему. Более подробно про это можно почитать в данном разделе документации. Сразу заметим, что такой сценарий использования может оказаться не всегда удобным, или даже невозможным, т.к. пользователь статического анализатора не всегда имеет возможность модифицировать сборочный сценарий проекта, с которым он работает.
  • После непосредственной интеграции в сборочный процесс статического анализа PVS-Studio, у пользователя возникает необходимость как-то изучать результаты работы анализатора. Это, в свою очередь, может потребовать создания специальной утилиты для преобразования отчета анализатора в формат, удобный для пользователя. Стоит отметить, что при наличии среды Visual Studio, отчёт ядра анализатора PVS-Studio.exe всегда можно просмотреть с помощью плагина-расширения PVS-Studio для данной среды.
  • Наконец, в случае, когда анализатор находит в коде реальные ошибки, возникает необходимость исправить их в исходных файлах проверяемого проекта.

Для решения этих проблем можно воспользоваться инструментом C and C++ Compiler Monitoring UI (Standalone.exe).

https://import.viva64.com/docx/manual/Standalone_ru/image1.png

Рисунок 1 - Compiler Monitoring UI

Compiler Monitoring UI предоставляет возможности для "бесшовной" проверки кода, независимо от используемых компилятора или сборочной системы, а затем позволяет работать с результатами анализа, предоставляя пользовательский интерфейс, схожий с Visual Studio плагином PVS-Studio. Также Compiler Monitoring UI позволяет работать и с отчётом анализатора, полученным с помощью прямой его интеграции в сборочную систему, при отсутствии у пользователя среды Visual Studio. Рассмотрим далее эти возможности.

Анализ исходных файлов с помощью отслеживания запуска компиляторов

Compiler Monitoring UI предоставляет пользовательский интерфейс для системы отслеживания компиляции. Сама система отслеживания (консольная утилита CLMonitor.exe) может использоваться и независимо от Compiler Monitoring UI, например, для интеграции статического анализа в систему автоматизированной сборки. Подробнее об использовании системы отслеживания компилятора можно почитать в этом разделе документации.

Для запуска отслеживания откройте диалог через Tools -> Analyze Your Files... (рисунок 2):

https://import.viva64.com/docx/manual/Standalone_ru/image3.png

Рисунок 2 - Диалог запуска мониторинга сборки

Нажмите "Start Monitoring". После этого будет запущен CLMonitor.exe, а основное окно среды будет свёрнуто.

Выполните сборку, а по её завершении нажмите на кнопку "Stop Monitoring" в окне в правом нижнем углу экрана (рисунок 3):

https://import.viva64.com/docx/manual/Standalone_ru/image4.png

Рисунок 3 - Диалог управления мониторингом

Если серверу мониторинга удалось отследить запуски компиляторов, будет запущен статический анализ исходных файлов. По окончании вы получите обычный отчёт о работе PVS-Studio (рисунок 4):

https://import.viva64.com/docx/manual/Standalone_ru/image5.png

Рисунок 4 - Результаты работы сервера мониторинга и статического анализатора

Результаты работы могут быть сохранены в виде XML файла (файла с расширением plog) для дальнейшего использования с помощью команды меню File -> Save PVS-Studio Log As...

Инкрементальный анализ при использовании системы мониторинга компиляции

Способ проведения инкрементального анализа аналогичен тому, как проводится анализ всего проекта. Ключевое отличие состоит в необходимости выполнения не полной, а инкрементальной сборки. В таком случае будут отслежены запуски компиляторов для модифицированных файлов, что позволит проверить только их. В остальном процесс анализа полностью идентичен тому, что описан выше, в разделе "Анализ исходных файлов с помощью отслеживания запуска компиляторов".

Работа со списком диагностических сообщений

После того, как был получен отчёт с предупреждениями анализатора, можно сразу начать просматривать сообщения и править код. Также в Compiler Monitoring UI можно загрузить и отчёт, полученный ранее. Для этого нужно воспользоваться пунктом меню 'File|Open PVS-Studio Log...'.

Различные механизмы подавления и фильтрации сообщений идентичны плагину Visual Studio и доступны в окне настроек 'Tools|Options...' (рисунок 5).

https://import.viva64.com/docx/manual/Standalone_ru/image7.png

Рисунок 5 - Настройки анализа и механизмы фильтрации сообщений

С помощью окна Analyzer Output можно осуществлять навигацию по предупреждениям анализатора, размечать сообщения как ложные срабатывания и добавлять фильтры для сообщений. Интерфейс для работы с предупреждениями анализатора в Compiler Monitoring UI идентичен интерфейсу окна вывода в плагине для Visual Studio. С подробным описанием окна вывода сообщений можно ознакомиться в данном разделе документации.

Навигация и поиск в исходном коде

Хотя встроенный редактор Compiler Monitoring UI не имеет такой же мощной и удобной системы навигации и автодополнения, как Microsoft IntelliSense в среде Visual Studio или им подобным, Compiler Monitoring UI предоставляет несколько механизмов поиска, которые могут упростить работу с результатами анализа.

Помимо обычного поиска в открытом файле (Ctrl + F), Compiler Monitoring UI имеет также диалог Code Search для текстового поиска в открытых файлах и директориях файловой системы. Этот диалог доступен через пункт меню 'Edit|Find & Replace|Search in Source Files...' (Рисунок 6):

https://import.viva64.com/docx/manual/Standalone_ru/image9.png

Рисунок 6 - Диалог поиска Compiler Monitoring UI

Диалог поддерживает поиск в текущем файле, всех открытых файлах, либо в произвольной директории файловой системы. Поиск можно в любой момент остановить, нажав Cancel в появившемся модальном окне. Результаты, при появлении первого совпадения, сразу начнут отображаться в дочернем окне Code Search Results (рисунок 7):

https://import.viva64.com/docx/manual/Standalone_ru/image10.png

Рисунок 7 - Результаты текстового поиска в исходных файлах проекта

Конечно, при необходимости найти места объявления и\или использования какого-либо идентификатора или макроса, обычный текстовый поиск может оказаться чересчур громоздким или долгим. В этом случае вы можете воспользоваться механизмом поиска по зависимостям и навигации по #include макросам.

Поиск по зависимостям в файлах позволяет искать символ\макрос именно в тех файлах, которые непосредственно участвовали при компиляции, а точнее, при последующем препроцессировании файлов, при их проверке анализатором. Для запуска поиска по зависимостям, откройте контекстное меню на символе, использование которого вы хотите посмотреть (рисунок 8):

https://import.viva64.com/docx/manual/Standalone_ru/image12.png

Рисунок 8 - Поиск символа по зависимостям

Результаты поиска, по аналогии с текстовым поиском, начнут выдаваться в отдельном дочернем окне Find Symbol Results. Поиск можно в любой момент остановить, нажав на Cancel в status bar'е главного окна Compiler Monitoring UI рядом с индикатором прогресса.

Навигация по #include макросам позволяет открывать в редакторе кода Compiler Monitoring UI файл, добавленный в текущий файл через такой макрос. Для открытия include'а также нужно воспользоваться контекстным меню редактора (рисунок 9):

https://import.viva64.com/docx/manual/Standalone_ru/image14.png

Рисунок 9 - Навигация по include'ам

Стоит помнить, что информация о зависимостях доступна не для любого исходного файла, открытого в Compiler Monitoring UI. В ситуации, когда база зависимостей недоступна для Compiler Monitoring UI, описанные выше пункты контекстного меню доступны также не будут.

База зависимостей создаётся только тогда, когда анализ запущен непосредственно из самого Compiler Monitoring UI. При открытии произвольного C/C++ исходника такой информации у Compiler Monitoring UI не будет. Заметим, что при сохранении результата работы анализатора в виде plog файла, в случае если этот результат был получен в самом приложении Compiler Monitoring UI, рядом с plog файлом будет создан также соответствующий ему специальный dpn файл, содержащий зависимости проверенных файлов. Наличие dpn файла рядом с plog файлом отчёта сделает возможным поиск по зависимостям, если такой plog файл будет открыт в Compiler Monitoring UI.

Советы по повышению скорости работы PVS-Studio

Любой статический анализатор кода работает медленнее компилятора. Это объясняется тем, что компилятор должен отработать очень быстро, пусть и в ущерб глубине анализа. Статические анализаторы вынуждены хранить дерево разбора, чтобы иметь возможность собрать большее количество информации. Хранение дерева увеличивает расход памяти, а множество проверок делает обход дерева ресурсоемкой и медленной операцией. На самом деле всё это не так критично, так как анализ более редкая операция, чем компиляция и пользователи готовы подождать. Тем не менее, всегда хочется, чтобы инструмент работал быстрее. В статье собраны рекомендации, позволяющие существенно увеличить скорость работы PVS-Studio.

Сначала перечислим коротко все рекомендации для того, чтобы пользователи сразу же могли понять, как им улучшить время работы анализатора:

  • Используйте многоядерный компьютер с большим объемом оперативной памяти.
  • Используйте SSD диск и для системы, и для проверяемого проекта.
  • Настройте (или выключите) антивирус.
  • По возможности используйте Clang в качестве препроцессора вместо Visual C++ (задается в настройках PVS-Studio) на Visual Studio 2010 и 2012.
  • Исключите из анализа лишние библиотеки (задается в настройках PVS-Studio).

Рассмотрим все эти рекомендации более подробно, с пояснениями, почему они позволяют работать быстрее.

Используйте многоядерный компьютер с большим объемом оперативной памяти

PVS-Studio давно (с версии 3.00, вышедшей в 2009 году) поддерживает работу в несколько потоков. Распараллеливание выполняется на уровне файлов. Если анализ выполняется на четырех ядрах, то одновременно проверяется четыре файла. Такой уровень параллелизма позволяет обеспечить существенное повышение производительности. По нашим замерам разница во времени работы на тестовых проектах очень заметна. Анализ в один поток выполняется за 3 часа 11 минут, в то время как анализ в четыре потока выполняется за 1 час 11 минут (данные получены на машине с четырьмя ядрами и восемью гигабайтами оперативной памяти). Отличие в 2.7 раза.

Для каждого потока анализатора рекомендуется иметь не менее одного гигабайта оперативной памяти. В противном случае (если будет много потоков и мало оперативной памяти) будет использоваться файл подкачки, что приведет к замедлению работы. При необходимости можно ограничить количество потоков анализатора с помощью настроек PVS-Studio Options -> Common Analyzer Settings -> Thread Count (документация). По умолчанию запускается столько потоков, сколько ядер в системе.

Рекомендуем использовать машину с четырьмя ядрами и восемью гигабайтами оперативной памяти или мощнее.

Используйте SSD диск и для системы, и для проверяемого проекта

Медленный жесткий диск, как ни странно, является очень слабым местом в работе анализатора кода. Но надо пояснить механизм работы анализатора для того, чтобы было понятно, почему это так. Для того, чтобы выполнить анализ файла, необходимо сначала его препроцессировать, т.е. раскрыть все #define, подставить все #include и т.п. Файл после препроцессинга имеет размер в среднем 10 мегабайт и записывается на диск в папку проекта. Затем уже читается анализатором и начинается его разбор. Рост файла происходит как раз за счет вставки содержимого #include-файлов, которые читаются из системных папок.

Привести конкретные результаты измерений влияния SSD на скорость анализа сложно, так как для этого надо тестировать абсолютно одинаковые машины, различающиеся лишь типом диска, однако, на глаз ускорение очень существенно.

Настройте (или выключите) антивирус

Анализатор кода является сложной и подозрительной программой с точки зрения антивируса по характеру своей работы. Сразу оговоримся, что речь не идет о том, что анализатор распознается как вирус - мы это регулярно проверяем. Кроме того, мы используем сертификат подписи кода. Обратимся опять к описанию работы анализатора кода.

На каждый анализируемый файл запускается отдельный процесс анализатора (модуль PVS-Studio.exe). Если в проекте 3000 файлов, то столько раз и будет запущен PVS-Studio.exe. Для своей работы PVS-Studio.exe вызывает настройку переменных окружения Visual C++ (файлы vcvars*.bat). Также во время работы создается большое количество препроцессированных файлов (*.i), по одному на каждый компилируемый файл. Используются вспомогательные командные (.cmd) файлы.

Все это хоть и не является вирусной активностью, тем не менее, заставляет любой антивирус тратить большое количество ресурсов на бесполезную проверку одного и того же.

Мы рекомендуем сделать следующие исключения в настройках антивируса:

  • Не проверять системные папки с Visual Studio:
    • C:\Program Files (x86)\Microsoft Visual Studio 11.0
    • C:\Program Files (x86)\Microsoft Visual Studio 12.0
    • C:\Program Files (x86)\Microsoft Visual Studio 14.0
    • и т.д.
  • Не проверять папку с PVS-Studio:
    • C:\Program Files (x86)\PVS-Studio
  • Не проверять папку проекта с кодом:
    • Например, C:\Users\UserName\Documents\MyProject
  • Не проверять исполняемые файлы Visual Studio:
    • C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\devenv.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\devenv.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe
    • и т.п.
  • Не проверять исполняемые файлы компилятора cl.exe (разных версий):
    • C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\x86_amd64\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin\amd64\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\x86_amd64\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin\amd64\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\x86_amd64\cl.exe
    • C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\amd64\cl.exe
    • и т.п.
  • Не проверять исполняемые файлы PVS-Studio и Clang (разных версий):
    • C:\Program Files (x86)\PVS-Studio\x86\PVS-Studio.exe
    • C:\Program Files (x86)\PVS-Studio\x86\clang.exe
    • C:\Program Files (x86)\PVS-Studio\x64\PVS-Studio.exe
    • C:\Program Files (x86)\PVS-Studio\x64\clang.exe

Возможно, приведенный список избыточен, но он дан именно в таком виде для того, чтобы можно было вне зависимости от конкретного антивируса указать, какие файлы и процессы проверять не надо.

Иногда, может быть, антивирус вообще не используется на машине (например, на специальном компьютере для сборок и запуска анализатора кода). В этом случае скорость работы будет наибольшая. Так как даже если в антивирусе указаны перечисленные выше исключения, на их проверку все равно будет тратиться время.

Наши тестовые измерения показывают, что агрессивно настроенный антивирус может давать замедление работы анализатора кода в два и более раз.

В Visual Studio 2010 и 2012, по возможности используйте Clang в качестве препроцессора вместо Visual C++ (задается в настройках PVS-Studio)

Для препроцессирования файлов в PVS-Studio используется внешний препроцессор. В среде Visual Studio по умолчанию используется нативный препроцессор Microsoft Visual C++ - cl.exe. В PVS-Studio 4.50 появилась поддержка второго независимого препроцессора Clang, который лишен ряда недостатков препроцессора от Microsoft (хотя и имеет свои недостатки).

В некоторых старых версия Visual Studio (2010 и 2012), препроцессор cl.exe работает значительно медленнее, чем clang. Использование препроцессора Clang в этих средах позволяет повысить скорость работы в 1.5-1.7 раз.

Однако, здесь есть нюанс, который надо учитывать. Указать используемый препроцессор можно в настройках PVS-Studio Options -> Common Analyzer Settings -> Preprocessor (документация). Доступны варианты: VisualCPP, Clang и VisualCPPAfterClang. Первые два варианта очевидны, а третий вариант означает, что сначала будет использоваться Clang. В случае, если при препроцессировании будут ошибки, то затем файл будет заново препроцессирован с помощью Visual C++.

Если ваш проект проверяется без проблем с помощью Clang, то вы можете использовать стандартное значение VisualCPPAfterClang или Clang - без разницы. Однако, если ваш проект может быть проверен только с помощью Visual C++, рекомендуем указать именно это значение, чтобы анализатор не запускал напрасно Clang в попытках препроцессировать им.

Исключите из анализа лишние библиотеки (задается в настройках PVS-Studio)

Любой крупный программный проект использует много сторонних библиотек, таких как zlib, libjpeg, Boost и др. Иногда эти библиотеки собираются отдельно, и тогда в основном проекте доступны только заголовочные и библиотечные (lib) файлы. А иногда библиотеки очень плотно интегрированы в проект, фактически становясь его частью. В этом случае при компиляции основного проекта компилируются также и файлы с кодом от этих библиотек.

Анализатору PVS-Studio можно указать, чтобы он не проверял код сторонних библиотек. Ведь даже если там и будут найдены какие-то ошибки, то, скорее всего, вы их править не станете. Но исключая из анализа такие папки можно существенно увеличить общую скорость анализа.

Также есть смысл исключить из анализа код, который долгое время не будет гарантированно меняться.

Для того чтобы исключить из анализа какие-то папки или отдельные файлы, используйте настройки PVS-Studio -> Don't Check Files (документация).

Для исключения папок можно указать в списке папок либо одну общую папку вроде c:\external-libs, либо явно перечислить некоторые из них: c:\external-libs\zlib, c:\external-libs\libjpeg и т.д. Можно указывать полный путь, относительный путь или маску. Например, достаточно указать zlib и libjpeg в списке папок - это автоматически будет трактоваться как папка с маской *zlib* и *libjpeg*. Подробнее смотрите в документации.

Итоги

Перечислим еще раз способы повысить скорость работы PVS-Studio:

  • Используйте многоядерный компьютер с большим объемом оперативной памяти.
  • Используйте SSD диск и для системы, и для проверяемого проекта (Update: для PVS-Studio версии 5.22 и выше, размещение самого проекта на SSD уже не оказывает влияние на скорость проверки).
  • Настройте (или выключите) антивирус.
  • В Visual Studio 2010 и 2012 по возможности используйте Clang в качестве препроцессора вместо Visual C++ (задается в настройках PVS-Studio).
  • Исключите из анализа лишние библиотеки (задается в настройках PVS-Studio).

Наибольший эффект достигается при одновременном применении наибольшего числа из этих рекомендаций.

Устранение неисправностей при работе PVS-Studio

Что необходимо знать в первую очередь о принципах работы PVS-Studio

В PVS-Studio можно выделить 2 главных компонента: command-line анализатор PVS-Studio.exe и IDE плагин, интегрирующий этот command-line анализатор в одну из поддерживаемых сред разработки (Microsoft Visual Studio). При этом сам command-line анализатор по принципу своей работы очень схож с компилятором — он вызывается для каждого из проверяемых файлов с параметрами, включающими в себя, в том числе, и оригинальные параметры компиляции этого файла. Затем анализатор вызывает необходимый ему препроцессор (опять, в соответствии с препроцессором, используемым при компиляции проверяемого файла) и производит непосредственный анализ полученного препроцессированного временного файла, т.е. файла, в котором раскрыты все include и define директивы.

Таким образом, command-line анализатор, как, впрочем, и компилятор (например, компилятор Visual C++ cl.exe), не предназначен для непосредственного использования конечным пользователем. Продолжая аналогию, компиляторы используются в большинстве случаев не напрямую, а с помощью специальной сборочной системы. Такая система подготавливает параметры запуска для каждого из собираемых файлов, а также, обычно, осуществляет распараллеливание самой сборки по имеющимся логическим процессорам для оптимизации затрачиваемого времени. Аналогом как раз такой сборочной системы для конечного пользователя и выступает IDE плагин PVS-Studio.

Но использование анализатора PVS-Studio.exe не ограничивается IDE плагинами. Как уже было сказано выше, command-line анализатор очень близок в своём использовании непосредственно к компилятору. Соответственно, его вызов можно встроить, при необходимости, и напрямую в сборочную систему, наравне с самим компилятором. Такой вариант может оказаться полезным при использовании для сборки не поддерживаемого нами сценария, такого как, например, custom-made сборочная система или IDE, отличная от Visual Studio. Заметьте, что PVS-Studio.exe поддерживает проверку исходных файлов, предназначенных для компиляторов gcc, clang и cl (включая специфические ключевые слова и конструкции).

Например, если ваш проект собирается в IDE Eclipse с помощью gcc, вы можете встроить проверку PVS-Studio в ваши makefile сборочные сценарии. Единственное ограничение - PVS-Studio.exe работает только в операционных системах семейства Windows NT.

Помимо IDE плагинов в дистрибутиве мы предоставляем также плагин для сборочной системы Microsoft MSBuild, которая используется для сборки Visual C++ проектах в IDE Visual Studio, начиная с версии 2010. Но, не стоит пут