Bug search in C/C++ code and a few questions

[Sidorenko Petr <sidorenko54312 at yandex dot com>]

Hello GDB Development,

We would like to invite you to read a small post on the static analysis methodology which allows programmers to detect plenty of bugs as early as at the coding stage.

You show interest in the C/C++ language which is indicated by http://www.sourceware.org/ml/gdb/2013-12/msg00041.html . So we thought that you might be interested in this post. Sorry if we are wrong; in this case, please just reply us with an empty email and I promise we wonât bother you anymore.
Every programmer makes mistakes many of which are awfully plain. No kidding. Just take a look at this code fragment:

if (t1.width() != t2.width() || t2.height() != t2.height()) {

The error here is that the return result of the t2.height() function is compared to itself instead of that of the t1.height() function. You may think this example is taken from some studentâs lab work task. But actually it was found in the Qt library in the qCompare function comparing two images.

No one is safe from mistakes like that. Besides typos, there is also the Copy-Paste technique that can fail a developer. The following is an example of what string copying may result in, taken from the Unreal Engine game engineâs code:

return
  Position.X >= Control.Center.X - BoxSize.X * 0.5f &&
  Position.X <= Control.Center.X + BoxSize.X * 0.5f &&
  Position.Y >= Control.Center.Y - BoxSize.Y * 0.5f &&
  Position.Y >= Control.Center.Y - BoxSize.Y * 0.5f;

The last line is a duplicate of the one before it. The programmer forgot to change a minus to a plus in it and replace >= to <=.

Most of bugs like those are fixed at the testing stage but some keep inhabiting the code and getting on developersâ nerves. They can be found through code review. But this method is too expensive to be used as an everyday practice. And this is where static code analysis tools come in handy. These utilities can analyze softwareâs source code to detect various abnormalities without ever getting tired. These abnormalities are usually nothing but errors or carelessly written code.

The most important thing is that static analyzers catch bugs at the earliest development stage â right after the code has been written or modified. This helps to reduce the number of errors that make it through to the testing stage.

Itâs all clear with typos, but analyzers can also detect bugs programmers are simply not aware of. If you show them a piece of code with such an error and ask to find it, they will fail as they simply do not know of that bug pattern. For example:

char* php_md5_crypt_r(const char *pw,const char *salt, char *out)
{
  unsigned char final[16];
  .....
  /* Don't leave anything around in vm they could use. */
  memset(final, 0, sizeof(final));
  return (passwd);
}

Whatâs wrong here? The private data wonât actually be erased in this code. Modern compilers tend to remove memset()-function calls as the "final" buffer is not used after having been cleared. And since it is not used, then thereâs no need to clear it. The analyzer is aware of this detail and suggests that the user replace a memset() function with one of the functions designed specifically for cases like this.

And there is a huge pile of other subtleties like that and one canât know them all, so the analyzer would be very useful if you care about the safety and reliability of your code. We can say that static analyzers contain a knowledge base on a variety of bug patterns collected from a number of various sources.

Our goal is to get a better understanding of how programmers treat static analysis, their opinions of this methodology and ways they use it. If you are interested in this topic, please answer a few questions:
1. Did you know about static analysis tools and their purpose before?
2. If you are not familiar with static analysis or would like to know more about it, we could send you a collection of links to interesting, quality articles on this subject. Would you like us to do that?
3. What code improvement techniques are employed in your company? For example: TDD, pair programming, manual review, etc.
4. Have you ever used static analyzers in your work? If yes, what tools and with what programming languages?
5. If you have used such tools, what is your impression of them? What did or didnât you like about them?
6. Under which operating system and IDE do you develop your C/C++ programs?

Looking forward to your answers! Thank you!

Best regards, Pyotr Sidorenko
"TInfo" Research agency