Lint your code: Find probable mistakes much before testing
Subscribe To Our Feed | Follow Us On Twitter | Get Updates on Email
Every programmer, no matter how great he is, makes mistakes sometime or the other while coding. Although every compiler tries its best to put across every possible error during compilation,many mistakes skip the wrath of compiler. Some are seemingly very innocent and very tough to be caught even during code review, sometimes even get through the cycle of testing. The real face of these mistakes show up always on the customer side by crashing the system.
Consider the following example:
int multiply(int m, int n) { int result = 0; result = m * n; return result; } void func() { int m = 32767; int n = 32767; int result = 0; result = multiply( m, n ); }
In this example, if you notice, the result always overrun the maximum value of an integer (int being of 16 bits). Now, for any compiler, this code seems to be perfect. But if you lint this code, the lint tool will definitely raise a warning about this potential bug. This bug if overlooked, can cause havoc in any system in crucial scenarios.
Similarly, there are many more example like these which can be caught while linting the code. Quite a few significant but obvious problems like buffer overrun, array index out of bounds, uninitialized variables causing junk in junk out can be caught using any of the good lint tools. This process of linting makes the code safe, secure and strong enough to withstand any kind of malicious input injections or buffer overrun attacks. Ofcourse, the complex scenarios can get skipped by some of the tools but still, it definitely is a better steo to catch the bug early. Quite a few tools are available in the market but i’ll recommend a tools can PC-Lint(Windows)/FlexLint(Linux). This tool is pretty good as it catches almost every obvious flaw which gets skipped by the developers or code reviewers eyes. It follows the guidelines given in MISRA (Motor Industry Software Reliability Assocation)standard and strictly adhers to that.
These linting tools generally have their properietary algorithms but in general, they all follow the same approach of static analysis of source code. Following are examples of some of the problems which these tools are capable of finding during the lint process.
Linting your code during development is very important as it can make your code much safer. It definitely does add to the build time and it might take few extra seconds to get the final object file, but isn’t it worth the hassle if you are saved from deadly bugs?
© Safer Code | Lint your code: Find probable mistakes much before testing
|
Liked this post? Get FREE Updates Subscribe to RSS feed 
|
Related posts
Tags: buffer overflow, C, Flex Lint, LINT, MISRA, PC Lint, Safety, warnings
At a company I used to work for we would use Flexlint and Klocwork to scan the code. While the tools worked great they also had considerable flaws. I don’t remember exact figures but roughly 60% (or more) of the potential flaws returned where false positives. Another interesting thing which shouldn’t surprise anyone was that they both generally returned the exact same errors.
Don’t get me wrong, I’m all for it. But don’t bet your code on it.
Yeah, I’ve used klocwork as well. All these linting tools do give false positives but basically I take them as “hints” or “potential” bugs. So, one should take the reports with a big grain of salt, but it is indeed helpful to actually go through all the errors and atleast have an explanation for each one even if it is a false positive (otherwise u can’t say it was a false positive
)
The most important thing is that you really try to understand why there is a warning. It’s not unusual that people treat such a warning incorrectly and make their code worse. Consider the following:
char c = …;
if (islower(c)) … ;
This will typically gain a warning which tells you islower() takes an int as parameter. I’ve seen code where people added a cast to int to suppress this warning. That didn’t gain them anything except hiding the useful warning. The bug is still there but the warning is gone – because the cast to int implies “I know what I’m doing”. What the warning tried to tell you is that “char” can be either signed or unsigned depending on the platform or even the current compiler settings. The specification of islower() explicitely states that the passed value must be either EOF or in the range of an unsigned char. So the right thing could be adding a cast to unsigned char. In most contexts it is, like inspecting characters of a C string. Passing any other value gains undefined behavior which is a deadly sin for any C developer.
Often there is really nothing you can change in your code to make the warning go away and it can very well be a better – maybe the only correct decision – to ignore it because in the context your code is used in, it is absolutely correct, but inspection tool can’t see it because it doesn’t have all the information you have. After all, a warning is a warning. Not more, not less.