Документация по анализатору кода PVS-Studio компании ООО "СиПроВер" (www.viva64.com)

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

  • Введение
  • Применение анализатора кода
  • Настройки PVS-Studio
  • Описание диагностируемых ошибок
    • Проблемы при работе анализатора кода
      • 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. Verification of CLR projects is not implemented. Incorrect diagnostics are possible.
      • V008. Unable to start the analysis on this file.
    • Диагностика 64-битных ошибок (Viva64)
      • V101. Implicit assignment type conversion to memsize type.
      • V102. Usage of non memsize type for pointer arithmetic.
      • V103. Implicit type conversion from memsize 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' declared with 32-bit type argument, but 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))"
      • 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.
      • V220. Suspicious sequence of types castings: memsize -> 32-bit integer -> memsize.
      • 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.
    • Диагностика общего назначения (General Analysis)
      • 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. The 'throw' operator inside the destructor should be placed within the try..catch block. Raising exception inside the destructor is illegal.
      • 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 containing 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 the 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' operator is incorrect for the HRESULT type value 'Foo'. The SUCCEEDED or FAILED macro should be used instead.
      • V546. Member of a class is initialized by itself: 'Foo(Foo)'.
      • V547. Expression is always true/false.
      • V548. Consider reviewing type casting. TYPE X[][] in 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 to temporary local object.
      • V559. Suspicious assignment inside the condition expression of 'if/while' operator.
      • 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. Undefined behavior. The variable is modified while being used twice between sequence points.
      • 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 casted 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' operators 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 method table 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 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. The code's operational logic does not correspond with its formatting.
      • 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.
      • 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.
      • 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.
      • 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 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.
    • Диагностика анализа производительности (Optimization)
      • 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'.
    • Диагностика параллельных ошибок (VivaMP)
      • V1000. Did you forget to enable the /openmp compiler option?
      • V1001. Missing 'parallel' keyword.
      • V1002. Missing 'omp' keyword.
      • V1003. Missing 'for' keyword. Each thread will execute the entire loop.
      • V1004. Nested parallelization of a 'for' loop.
      • V1005. The 'ordered' directive is not present in an ordered loop.
      • V1006. Missing omp.h header file. Use '#include <omp.h>'.
      • V1101. Redefining number of threads in a parallel code.
      • V1102. Non-symmetrical use of set/unset functions for the following lock variable(s): foo.
      • V1103. Threads number dependent code. The 'omp_get_num_threads' function is used in an arithmetic expression.
      • V1104. Redefining nested parallelism in a parallel code.
      • V1201. Concurrent usage of a shared resource via an unprotected call of the 'foo' function.
      • V1202. The 'flush' directive should not be used for the 'foo' variable, because the variable has pointer type.
      • V1203. Using the 'threadprivate' directive is dangerous, because it affects the entire file. Use local variables or specify access type for each parallel block explicitly instead.
      • V1204. Data race risk. Unprotected static variable declaration in a parallel code.
      • V1205. Data race risk. Unprotected concurrent operation with the 'foo' variable.
      • V1206. Data race risk. The value of the 'foo' variable can be changed concurrently via the 'bar' function.
      • V1207. Data race risk. The 'foo' object can be changed concurrently by a non-const function.
      • V1208. The 'foo' variable of reference type cannot be private.
      • V1209. Warning: The 'foo' variable of pointer type should not be private.
      • V1210. The 'foo' variable is marked as lastprivate but is not changed in the last section.
      • V1211. The use of 'flush' directive has no sense for private 'foo' variable, and can reduce performance.
      • V1212. Data race risk. When accessing the array 'foo' in a parallel loop, different indexes are used for writing and reading.
      • V1301. The 'throw' keyword cannot be used outside of a try..catch block in a parallel section.
      • V1302. The 'new' operator cannot be used outside of a try..catch block in a parallel section.
      • V1303. The 'foo' function which throws an exception cannot be used in a parallel section outside of a try..catch block.
    • Реализовано по запросам пользователей
      • V2001. Consider using the extended version of the 'foo' function here: bar.
      • V2002. Consider using the 'Ptr' version of the 'foo' function here: bar.
      • 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 constant pointer/reference.
      • V2010. Handling of two different exception types is identical.
  • Дополнительная информация