Webinar: Evaluation - 05.12
The post is small because this is a rare case when we find almost no errors in a project when checking it with PVS-Studio. However, we've decided to write about this project for the world to know its heroes.
We regularly check various open-source projects and write posts about it. Developers are of course informed about the results. We haven't got much time to check projects recently, as we were very busy providing support for Embarcadero C++Builder 2009-XE3. But now we continue our traditional checks. It is especially interesting now that our tool has learned to analyze even more diverse projects. If you know any open-source projects for C++Builder that might be of interest to us, please let us know.
In the past we didn't write about projects in which nothing (or almost nothing) of interest had been found. But we have concluded that it's unfair. I'm sure that authors of clear projects will be pleased to know that we have appreciated the quality of their code highly.
The first project among these we'd like to tell you about is C++ REST SDK (codename "Casablanca"). This is a good code written in a contemporary style employing capabilities of C++11. We have checked it using our static code analyzer PVS-Studio and failed to find at least one significant bug. Our respect to the Microsoft developers who have created this library!
The analyzer has found only errors made deliberately for the testing purpose. For example, it has generated the warning "V539 Consider inspecting iterators which are being passed as arguments to function 'for_each'. test_runner.cpp 551" for the following code:
const std::vector<std::string> & failed =
testRunner.GetTestResults()->GetFailedTests();
std::for_each(failed.end(), failed.end(),
[](const std::string &failedTest)
{
std::cout << "**** " << failedTest
<< " FAILED ****" << std::endl << std::endl;
});
There were some other special test errors, but there's no point telling about them.
The only fragment that could be scarcely called an error is this one:
bool _close_fsb_nolock(....)
{
....
if ( fInfo->m_buffer != nullptr )
{
delete fInfo->m_buffer;
fInfo->m_buffer;
}
....
delete fInfo;
....
}
The following code should have been most likely written instead:
delete fInfo->m_buffer;
fInfo->m_buffer = 0;
But it's not that important, as the object located by the address 'fInfo' gets destroyed anyway. There are a couple of other fragments we could pick on, but it's not serious.
So our praise and a virtual medal go to the developers of Casablanca!
0