From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 78685 invoked by alias); 26 Mar 2015 11:41:29 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 78672 invoked by uid 89); 26 Mar 2015 11:41:29 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.1 required=5.0 tests=BAYES_50,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,SPF_PASS autolearn=no version=3.3.2 X-HELO: forward17j.cmail.yandex.net Received: from forward17j.cmail.yandex.net (HELO forward17j.cmail.yandex.net) (5.255.227.236) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Thu, 26 Mar 2015 11:41:27 +0000 Received: from web8j.yandex.ru (web8j.yandex.ru [IPv6:2a02:6b8:0:1619::308]) by forward17j.cmail.yandex.net (Yandex) with ESMTP id B3AA420FCA for ; Thu, 26 Mar 2015 14:41:22 +0300 (MSK) Received: from 127.0.0.1 (localhost [127.0.0.1]) by web8j.yandex.ru (Yandex) with ESMTP id 391F5121060; Thu, 26 Mar 2015 14:41:22 +0300 (MSK) Received: by web8j.yandex.ru with HTTP; Thu, 26 Mar 2015 14:41:21 +0300 From: Sidorenko Petr To: gdb@sourceware.org Subject: Bug search in C/C++ code and a few questions MIME-Version: 1.0 Message-Id: <6374741427370081@web8j.yandex.ru> Date: Thu, 26 Mar 2015 11:41:00 -0000 Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset=utf-8 X-SW-Source: 2015-03/txt/msg00100.txt.bz2 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