PVS-Studio Analyzer

Contents

• What bugs can PVS-Studio detect?
• List of all analyzer rules in XML
• General Analysis (C++)
• General Analysis (C#)
• General Analysis (Java)
• Diagnosis of micro-optimizations (C++)
• Diagnosis of 64-bit errors (Viva64, C++)
• Customers Specific Requests (C++)
• MISRA errors
• AUTOSAR errors
• OWASP errors (C++)
• OWASP errors (C#)
• OWASP errors (Java)
• Problems related to code analyzer

What bugs can PVS-Studio detect?

We grouped the diagnostic, so that you can get the general idea of what PVS-Studio is capable of.

As it is hard to do strict grouping, some diagnostics belong to several groups. For example, the incorrect condition "if (abc == abc)" can be interpreted both as a simple typo, but also as a security issue, because it leads to the program vulnerability if the input data are incorrect.

Some of the errors, on the contrary, couldn't fit any of the groups, because they were too specific. Nevertheless this table gives the insight about the functionality of the static code analyzer.

List of all analyzer rules in XML

You can find a permanent link to machine-readable map of all analyzer's rules in XML format here.

Table – PVS-Studio functionality.

As you see, the analyzer is especially useful is such spheres as looking for bugs caused by Copy-Paste and detecting security flaws.

To these diagnostics in action, have a look at the error base. We collect all the errors that we have found, checking various open source projects with 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.
• V1065. Expression can be simplified: check similar operands.
• V1066. The 'SysFreeString' function should be called only for objects of the 'BSTR' type.
• V1067. Throwing from exception constructor may lead to unexpected behavior.
• V1068. Do not define an unnamed namespace in a header file.
• V1069. Do not concatenate string literals with different prefixes.

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.
• V3159. Modified value of the operand is not used after the increment/decrement operation.
• V3160. Argument of incorrect type is passed to the 'Enum.HasFlag' method.
• V3161. Comparing value type variables with 'ReferenceEquals' is incorrect because compared values will be boxed.
• V3162. Suspicious return of an always empty collection.
• V3163. An exception handling block does not contain any code.
• V3164. Exception classes should be publicly accessible.
• V3165. The expression of the 'char' type is passed as an argument of the 'A' type whereas similar overload with the string parameter exists.
• V3166. Calling the 'SingleOrDefault' method may lead to 'InvalidOperationException'.
• V3167. Parameter of 'CancellationToken' type is not used inside function's body.
• V3168. Awaiting on expression with potential null value can lead to throwing of 'NullReferenceException'.
• V3169. Suspicious return of a local reference variable which always equals null.

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/for/while' 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.
• V6095. Thread.sleep() inside synchronized block/method may cause decreased performance.
• V6096. An odd precise comparison. Consider using a comparison with defined precision: Math.abs(A - B) < Epsilon or Math.abs(A - B) > Epsilon.
• V6097. Lowercase 'L' at the end of a long literal can be mistaken for '1'.
• V6098. The method does not override another method from the base class.
• V6099. The initial value of the index in the nested loop equals 'i'. Consider using 'i + 1' instead.
• V6100. An object is used as an argument to its own method. Consider checking the first actual argument of the 'Foo' method.
• V6101. compareTo()-like methods can return not only the values -1, 0 and 1, but any values.
• V6102. Inconsistent synchronization of a field. Consider synchronizing the field on all usages.
• V6103. Ignored InterruptedException could lead to delayed thread shutdown.
• V6104. A pattern was detected: A || (A && ...). The expression is excessive or contains a logical error.
• V6105. Consider inspecting the loop expression. It is possible that different variables are used inside initializer and iterator.
• V6106. Casting expression to 'X' type before implicitly casting it to other type may be excessive or incorrect.

Diagnosis of micro-optimizations (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.
• V831. Decreased performance. Consider replacing the call to the 'at()' method with the 'operator[]'.

Diagnosis of 64-bit errors (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.

Customers Specific Requests (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.

MISRA errors

• 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.
• V2574. MISRA. Functions should not be declared at block scope.
• V2575. MISRA. The global namespace should only contain 'main', namespace declarations and 'extern "C"' declarations.
• V2576. MISRA. The identifier 'main' should not be used for a function other than the global function 'main'.

AUTOSAR errors

• V3501. AUTOSAR. Octal constants should not be used.
• V3502. AUTOSAR. Size of an array is not specified.
• V3503. AUTOSAR. The 'goto' statement shouldn't jump to a label declared earlier.
• V3504. AUTOSAR. The body of a loop\conditional statement should be enclosed in braces.
• V3505. AUTOSAR. The function with the 'atof/atoi/atoll/atoll' name should not be used.
• V3506. AUTOSAR. The function with the 'abort/exit/getenv/system' name should not be used.
• V3507. AUTOSAR. The macro with the 'setjmp' name and the function with the 'longjmp' name should not be used.
• V3508. AUTOSAR. Unbounded functions performing string operations should not be used.
• V3509. AUTOSAR. Unions should not be used.
• V3510. AUTOSAR. Declaration should contain no more than two levels of pointer nesting.
• V3511. AUTOSAR. The 'if' ... 'else if' construct should be terminated with an 'else' statement.
• V3512. AUTOSAR. Literal suffixes should not contain lowercase characters.
• V3513. AUTOSAR. Every switch-clause should be terminated by an unconditional 'break' or 'throw' statement.
• V3514. AUTOSAR. The 'switch' statement should have 'default' as the last label.
• V3515. AUTOSAR. All integer constants of unsigned type should have 'U' suffix.
• V3516. AUTOSAR. A switch-label should only appear at the top level of the compound statement forming the body of a 'switch' statement.
• V3517. AUTOSAR. The functions from time.h/ctime should not be used.
• V3518. AUTOSAR. A switch-expression should not have Boolean type. Consider using of 'if-else' construct.
• V3519. AUTOSAR. The comma operator should not be used.
• V3520. AUTOSAR. Any label should be declared in the same block as 'goto' statement or in any block enclosing it.
• V3521. AUTOSAR. The loop counter should not have floating-point type.
• V3522. AUTOSAR. Unreachable code should not be present in the project.
• V3523. AUTOSAR. Functions should not have unused parameters.
• V3524. AUTOSAR. The value of uninitialized variable should not be used.
• V3525. AUTOSAR. Function with a non-void return type should return a value from all exit paths.
• V3526. AUTOSAR. Expression resulting from the macro expansion should be surrounded by parentheses.
• V3527. AUTOSAR. The return value of non-void function should be used.
• V3528. AUTOSAR. The address of an object with local scope should not be passed out of its scope.
• V3529. AUTOSAR. Floating-point values should not be tested for equality or inequality.
• V3530. AUTOSAR. Variable should be declared in a scope that minimizes its visibility.
• V3531. AUTOSAR. Expressions with enum underlying type should have values corresponding to the enumerators of the enumeration.
• V3532. AUTOSAR. Unary minus operator should not be applied to an expression of the unsigned type.
• V3533. AUTOSAR. Expression containing increment (++) or decrement (--) should not have other side effects.
• V3534. AUTOSAR. Incorrect shifting expression.
• V3535. AUTOSAR. Operand of sizeof() operator should not have other side effects.
• V3536. AUTOSAR. A pointer/reference parameter in a function should be declared as pointer/reference to const if the corresponding object was not modified.
• V3537. AUTOSAR. Subtraction, >, >=, <, <= should be applied only to pointers that address elements of the same array.
• V3538. AUTOSAR. The result of an assignment expression should not be used.
• V3539. AUTOSAR. Array indexing should be the only form of pointer arithmetic and it should be applied only to objects defined as an array type.
• V3540. AUTOSAR. There should be no implicit integral-floating conversion.
• V3541. AUTOSAR. A function should not call itself either directly or indirectly.
• V3542. AUTOSAR. Constant expression evaluation should not result in an unsigned integer wrap-around.
• V3543. AUTOSAR. Cast should not remove 'const' / 'volatile' qualification from the type that is pointed to by a pointer or a reference.
• V3544. AUTOSAR. The 'operator &&', 'operator ||', 'operator ,' and the unary 'operator &' should not be overloaded.
• V3545. AUTOSAR. Operands of the logical '&&' or the '||' operators, the '!' operator should have 'bool' type.
• V3546. AUTOSAR. Conversions between pointers to objects and integer types should not be performed.
• V3547. AUTOSAR. Identifiers that start with '__' or '_[A-Z]' are reserved.
• V3548. AUTOSAR. Functions should not be declared at block scope.
• V3549. AUTOSAR. The global namespace should only contain 'main', namespace declarations and 'extern "C"' declarations.
• V3550. AUTOSAR. The identifier 'main' should not be used for a function other than the global function 'main'.

OWASP errors (C++)

• V5001. OWASP. It is highly probable that the semicolon ';' is missing after 'return' keyword.
• V5002. OWASP. An empty exception handler. Silent suppression of exceptions can hide the presence of bugs in source code during testing.
• V5003. OWASP. The object was created but it is not being used. The 'throw' keyword could be missing.
• V5004. OWASP. Consider inspecting the expression. Bit shifting of the 32-bit value with a subsequent expansion to the 64-bit type.
• V5005. OWASP. 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.
• V5006. OWASP. More than N bits are required to store the value, but the expression evaluates to the T type which can only hold K bits.
• V5007. OWASP. Consider inspecting the loop expression. It is possible that the 'i' variable should be incremented instead of the 'n' variable.
• V5008. OWASP. Classes should always be derived from std::exception (and alike) as 'public'.
• V5009. OWASP. Unchecked tainted data is used in expression.
• V5010. OWASP. The variable is incremented in the loop. Undefined behavior will occur in case of signed integer overflow.
• V5011. OWASP. Possible overflow. Consider casting operands, not the result.
• V5012. OWASP. Potentially unsafe double-checked locking.

OWASP errors (C#)

• V5601. OWASP. Storing credentials inside source code can lead to security issues.
• V5602. OWASP. The object was created but it is not being used. The 'throw' keyword could be missing.
• V5603. OWASP. The original exception object was swallowed. Stack of original exception could be lost.
• V5604. OWASP. Potentially unsafe double-checked locking. Use volatile variable(s) or synchronization primitives to avoid this.
• V5605. OWASP. Unsafe invocation of event, NullReferenceException is possible. Consider assigning event to a local variable before invoking it.
• V5606. OWASP. An exception handling block does not contain any code.
• V5607. OWASP. Exception classes should be publicly accessible.

OWASP errors (Java)

• V5301. OWASP. An exception handling block does not contain any code.
• V5302. OWASP. Exception classes should be publicly accessible.
• V5303. OWASP. The object was created but it is not being used. The 'throw' keyword could be missing.
• V5304. OWASP. Unsafe double-checked locking.
• V5305. OWASP. Storing credentials inside source code can lead to security issues.

Problems related to code analyzer

• 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.