How PVS-Studio prevents rash code changes, example N6

Oct 20 2022

Author: Vladislav Stolyarov

Developers often make mistakes accidentally, or because they are in a hurry. Wondering how to find such mistakes quickly? Welcome to another article in the "How PVS-Studio prevents rash code changes" series. Today we're talking about the FreeCAD project.

1001_how_to_pvs-studio_protect_N6/image1.png

I'd like to start with explaining how I found an error. I'm sure that for our regular blog readers it's not a secret. Moreover, this article is the sixth one in the series! However, the newcomers to our blog may be interested in the way I found the error.

We have two approaches to work with open-source projects. The first approach is to choose an open-source project and perform a full check of its code base only once. The other approach is to regularly check a small list of open-source projects and find bugs only in the new code. This approach is much faster than viewing the full analyzer's report. Moreover, it helps detect potential errors rapidly. You can learn more about our monitoring of open-source projects and technologies that we use here.

Now, let's take a look at the error found by the PVS-Studio analyzer in the FreeCAD project. To see the whole picture, I tried to show you the problematic code fragment almost in full:

TechDraw::DrawPage* DrawGuiUtil::findPage(Gui::Command* cmd, bool findAny)
{
  ....
  //check Selection for a page
  std::vector<App::DocumentObject*> selPages = cmd->getSelection().
                     getObjectsOfType(TechDraw::DrawPage::getClassTypeId());
  if (selPages.empty()) 
  {
    //no page in selection, try this document
    auto docPages = cmd->getDocument()
                  ->getObjectsOfType(TechDraw::DrawPage::getClassTypeId());
    if (docPages.empty()) 
    {
        //we are only to look in this document, and there is no ....
        QMessageBox::warning(Gui::getMainWindow(), QObject::tr("No page found"),
                    QObject::tr("No Drawing Pages in document."));
      return nullptr;
    }
    if (docPages.size() > 1) 
    {
      //multiple pages in document, use active page if there is one
      Gui::MainWindow* w = Gui::getMainWindow();
      Gui::MDIView* mv = w->activeWindow();
      MDIViewPage* mvp = dynamic_cast<MDIViewPage*>(mv);
      if (mvp) 
      {
        QGSPage* qp = mvp->getViewProviderPage()->getQGSPage();
        return qp->getDrawPage();
      }
      else 
      {
        // none of pages in document is active, ask for help
        for (auto obj : selPages) // <=
        {
          ....
        }
        ....
      }
      ....
    }
    ....
  }
  ....
}

PVS-Studio issued the following warning on this code:

V1078: An empty container is iterated. The loop will not be executed.

So, we have the selPages container which is initialized by the getObjectsOfType function. The selPages.empty() check suggests that the container can be empty. If the condition is true, an attempt to bypass this container occurs in one of the nested conditions. However, its size does not change at this point.

This code fragment makes me wonder how it looked like before the commit. In case you're wondering the same question — here's the link to changed files.

1001_how_to_pvs-studio_protect_N6/image2.png

Now developers do not modify the selPages container but save the result to a new docPages variable. They also rewrote the code using a new variable everywhere but forgot to fix the range-based for loop.

So, the error wouldn't have gotten into the repository if developers had used static analysis regularly before committing the code. Even if you missed something during code review, the analyzer would highlight the problem place in the code.