QA C Source Code Analyzer
WARNING: This is a technical post…
I don’t know how many of you would have heard of the (in?)famous QAC software program that analyzes your C code for quality. I had the privilege of running it a couple of days ago on a few of the driver modules and among the errors thrown up were a few gems.
- C++ Style comments not allowed: OK, I’ll accept that. Some people say that it is preferable to use the standard block comments (/* … */) instead of the single line comments (// …) and I’m not about to counter that.
- Conversion between a pointer and integer is implementation defined: This particular error came up more than a few hundred times. The hardware I use contains configuration registers that are memory mapped and so I have to use a pointer to address them. QAC starts complaining…
- Conditions to be made explicit: In C (or C++), any expression evaluating to a non-zero quantity is treated as true in a condition. Similiarly, a zero value is treated as false. We had made use of this feature more than once, and once again, QAC began to complain…
- Every condition should have a block: (OK, this was not the actual text.) What this actually meant was that if I had a single statement to be executed if a particular condition was valid, I still had to enclose it with the curly braces. I’m actually for this kind of coding practice as it helps to trap quite a number of bugs. Where this really threw rocks at me was on a line like this:
while (<condition>);. We had a few lines where the software waits for a particular condition to happen (like a register bit getting set or reset). What QAC expected was more of the following:
while (<condition>)
{
;
}
This actually sounds crazy to me. I believe that there is no point in putting a null statement within curly braces while waiting. I also think that this kind of a statement would actually hinder the readability.
Now don’t get me wrong. I think QAC is a great tool for quality checks, but then again, some of those warnings can just be ignored…
June 6th, 2005 at 10:50 am
That kind of a software would help debug quite a lot of bugs - and also probably avoid cut and paste errors.
I certainly would love to get my hands on it.
June 6th, 2005 at 9:40 pm
Sat: You could try. But given that we have some pretty restrictive licensing stuff in the office, I don’t think that kind of power comes cheap.
June 8th, 2005 at 3:11 am
Hey Buddy,
How is u? wow… a great site indeed… i jus now found abt ur site in Hi5..
keep the gud work.. in case u dont remember me it is ur gud old frnd vivek of IT dept..
June 8th, 2005 at 3:39 am
Inhouse tool?
June 8th, 2005 at 7:35 am
Vivek: Hi da, nice to hear from you. What about you? Do you also have a blog?
Sat: Nope, its a bought tool. Available from Programming Research - also known as PRQA (I think)
June 11th, 2005 at 2:34 pm
Nirenjan,
I have been using QAC for nearly 2 years now. Very useful and powerful tool when it comes to spotting static errors
June 14th, 2005 at 6:34 am
Balaji: I totally agree with you. Apart from that one single point which I mentioned (the while loop), I have no complains about QAC. The problem came when I had to run it on some old code, which turned out to be pretty sloppy by QAC standards.