: Analyzer ignoring the effects of a function call?

Hi,

I think I am getting a false positive for IdempotentOperationChecker which is affecting another checker I am writing. Here is the program I am running the clang analyzer on:

#include<stdio.h>

int main(void)
{
int a = 5;
int b = 4;
int c = 10;

scanf("%d", &a);

if (a + b == 4) {
c = a + b;
}
return c;
}

I get:

\$clang --analyze d.cpp

d.cpp:12:15: warning: The left operand to ‘+’ is always 0
c = a + b;
~ ^

Why is it ignoring the scanf function call? Is this expected because the analyzer doesn’t do inter-procedural analysis? But even then I think it shouldn’t ignore the effects of the function call. Now this is happening because the LHSVal.isConstant(0) call inside the IdempotentOperationChecker is evaluating to true.

Arjun

It’s not ignoring the scanf call: if it were, it would think that ‘a’ was 5, not 0. No, here it’s presumably analyzing the dominating if condition and doing basic algebra.

John.

But how did it arrive at the conclusion that ‘a’ was ‘0’ when it is clearly unknown? If I don’t provide an intial value for ‘a’, it still reports the same warning. Does that mean that it is interpreting that ‘a’ is set to zero inside the function?

Inside your if statement, a is always 0. So the expression can be
simplified to "c = b;".

I've found clang's static analyzer of immense help with my iPhone App,
but the messages it presents are sometimes rather obscure in their
meaning.

Don Quixote de la Mancha
quixote@dulcineatech.com

The value of 'a' is unknown. The value of 'b' is known to be 4. In the if statement, for a + b to be equal to 4, a must be 4 - b = 4 - 4 = 0. So, within the body of the if statement, 'a' is known to be 0, since any other value would fail to satisfy the condition.

It inferred it from the dominating equality test. b is known to be 4, so the only way for a+b to equal 4 is if a is zero.

John.

Put another way: a is unknown only OUTSIDE the basic block of the true
case of the if. Within the basic block, it just has to be zero.

If you don't believe me, try putting "assert( a == 0)" inside the if
statement then run a bunch of tests on your code. The assert will
never trip.

Hi Don,

It would be helpful if you could file bugzilla bug reports for the error messages that you find especially obscure.

Thanks!
Anna.

Will do.

The error messages made a lot of sense once I figured them out, so
they must have made sense to whoever originally implemented them.
They mostly had to do with the conventions of Objective-C and Cocoa
Touch memory management.

I was really flummoxed by the advice that a lot of methods returned
objects that had retain counts of zero. What that really meant was
that their retain counts were presently one, but at a later time they
would be autoreleased. I was not supposed to release them myself.

These messages were in Xcode 4.0.2 and Xcode 4.1 while I was
developing an iOS App. Should I file my bug reports at
http://bugreport.apple.com/ or in CLangs Bugzilla?

Don Quixote

HI Don,

Filing a Bugzilla report (Product: clang, Component: Static Analyzer) will provide a faster feedback/more transparency. You can mention that you are using Xcode.

Cheers,
Anna.