Home
PVS-Studio Documentation
PVS-Studio Documentation by OOO "Program Verification Systems" (www.viva64.com)

PVS-Studio Documentation by OOO "Program Verification Systems" (www.viva64.com)

Introduction
Using the program
PVS-Studio Options
Error description
- Common
  - V001. A code fragment from 'file' cannot be analyzed.
  - V002. Some diagnostic messages may contain incorrect line number.
  - V003. Unrecognized error found...
  - V004. For a more precise verification, please select x64 or Itanium configuration instead of Win32.
  - 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.
  - V009. Intel C++ project toolset is not supported. Select Visual C++ toolset to verify this project.
- Diagnosis of 64-bit errors (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.
  - 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. Check the logical condition.
  - 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 matches it's 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.
  - 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.
- Diagnosis of parallel errors (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.
- Customer's Specific Requests
  - 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.
Additional information
- Credits and acknowledgements.

You can download full PVS-Studio documentation as single html file here: http://www.viva64.com/en/d/full

PVS-Studio Documentation by OOO "Program Verification Systems" (www.viva64.com)

For Developers:

Blog:

How we managed the task of implementing trial mode in the PVS-Studio code analyzer

Wade not in unknown waters. Part one

Tips on speeding up PVS-Studio

Our Articles:

How to make fewer errors at the stage of code writing. Part N4

PVS-Studio advertisement - static analysis of C/C++ code

PVS-Studio: analyzing ReactOS's code

News:

John Carmack about PVS-Studio

Free PVS-Studio licenses for MVPs

Our worker Andrey Karpov has been given the MVP award

Static Code Analyzer for C/C++/C++11

PVS-Studio Documentation by OOO "Program Verification Systems" (www.viva64.com)