26-10-2021, 12:14 PM
Hi,
We have a static analyzer that is reporting warnings related to 6-5-2 and 6-5-4 in the following code:
The warning is that the "loop counter v" is not compared against a relational operator (6-5-2) nor is it modified via ++ et al. (6-5-4).
The static analysis tool vendor claims this is not a false positive and indeed it's required by the MISRA rules.
Could you shed some light as to whether the code above is violating 6-5-2 and 6-5-4? Is "v" really a loop counter as per the MISRA definition? One could argue that the loop counter is the private member std::vector::__size, but is that really the scope of this rule?
This code pattern is very typical when implementing e.g. graph search, having a list of Nodes and inspecting them one by one until a condition is reached or the list of nodes is empty. The list of nodes can typically grow while inspecting each node, so iterator-based searches are not a good implementation alternative.
We have a static analyzer that is reporting warnings related to 6-5-2 and 6-5-4 in the following code:
Code:
std::vector<std::int32_t> v{};
// Fill vector
// ...
// Consume vector
while (!v.empty()) // <<< 6-5-2, 6-5-4 violated here?
{
std::int32_t const value{v.back()};
v.pop_back();
std::cout << value << "\n";
}
The warning is that the "loop counter v" is not compared against a relational operator (6-5-2) nor is it modified via ++ et al. (6-5-4).
The static analysis tool vendor claims this is not a false positive and indeed it's required by the MISRA rules.
Could you shed some light as to whether the code above is violating 6-5-2 and 6-5-4? Is "v" really a loop counter as per the MISRA definition? One could argue that the loop counter is the private member std::vector::__size, but is that really the scope of this rule?
This code pattern is very typical when implementing e.g. graph search, having a list of Nodes and inspecting them one by one until a condition is reached or the list of nodes is empty. The list of nodes can typically grow while inspecting each node, so iterator-based searches are not a good implementation alternative.