Hello Artur Laksberg,

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

You show interest in the C/C++ language which is indicated by https://group=
s.google.com/a/isocpp.org/forum/?fromgroups . So we thought that you might =
be interested in this post. Sorry if we are wrong; in this case, please jus=
t reply us with an empty email and I promise we won=E2=80=99t bother you an=
ymore.
Every programmer makes mistakes many of which are awfully plain. No kidding=
.. Just take a look at this code fragment:

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

The error here is that the return result of the t2.height() function is com=
pared to itself instead of that of the t1.height() function. You may think =
this example is taken from some student=E2=80=99s lab work task. But actual=
ly it was found in the Qt library in the qCompare function comparing two im=
ages.

No one is safe from mistakes like that. Besides typos, there is also the Co=
py-Paste technique that can fail a developer. The following is an example o=
f what string copying may result in, taken from the Unreal Engine game engi=
ne=E2=80=99s code:

return
  Position.X >=3D Control.Center.X - BoxSize.X * 0.5f &&
  Position.X <=3D Control.Center.X + BoxSize.X * 0.5f &&
  Position.Y >=3D Control.Center.Y - BoxSize.Y * 0.5f &&
  Position.Y >=3D 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 >=3D to <=3D.

Most of bugs like those are fixed at the testing stage but some keep inhabi=
ting the code and getting on developers=E2=80=99 nerves. They can be found =
through code review. But this method is too expensive to be used as an ever=
yday practice. And this is where static code analysis tools come in handy. =
These utilities can analyze software=E2=80=99s source code to detect variou=
s 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 earlies=
t development stage =E2=80=93 right after the code has been written or modi=
fied. This helps to reduce the number of errors that make it through to the=
 testing stage.

It=E2=80=99s all clear with typos, but analyzers can also detect bugs progr=
ammers 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 t=
hat 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=E2=80=99s wrong here? The private data won=E2=80=99t actually be erase=
d 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 n=
ot used, then there=E2=80=99s no need to clear it. The analyzer is aware of=
 this detail and suggests that the user replace a memset() function with on=
e of the functions designed specifically for cases like this.

And there is a huge pile of other subtleties like that and one can=E2=80=99=
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 cont=
ain a knowledge base on a variety of bug patterns collected from a number o=
f various sources.

Our goal is to get a better understanding of how programmers treat static a=
nalysis, their opinions of this methodology and ways they use it. If you ar=
e 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 a=
rticles on this subject. Would you like us to do that?
3. What code improvement techniques are employed in your company? For examp=
le: 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 o=
r didn=E2=80=99t 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

--=20

---=20
You received this message because you are subscribed to the Google Groups "=
ISO C++ Standard - Future Proposals" group.
To unsubscribe from this group and stop receiving emails from it, send an e=
mail to std-proposals+unsubscribe@isocpp.org.
To post to this group, send email to std-proposals@isocpp.org.
Visit this group at http://groups.google.com/a/isocpp.org/group/std-proposa=
ls/.

.