[cfe-dev] Clang Analysis of several open source projects.

Peter Lawrence peterl95124 at sbcglobal.net
Mon May 16 09:28:38 PDT 2011


Erik,
       I too have been bothered by the lack of sophistication in  
static analyzers, my most recent was
something like this:

	int foo ()
	{
		if (...) {
			return x;
		} else switch (...) {
		case 1: return y;
		default: return z;
		}
	}

and the compiler complained that the function could run-off-the-end  
without returning a value.!.

(the problem was with gcc, I have not tried clang on my code yet,  
since that would require clang/llvm
self-hosting, which I am not sure works yet ?)



as this email-thread has evolved into a discussion of what is  
necessarily missed by not doing
inter-procedural (whole-program) analysis,  I am still confounded by  
what is not being done that
could be done with intra-procedural analysis which is very much more  
doable  (and again, maybe
clang is already doing better in that department than gcc, but I have  
not yet done the experiment
to find out...)


so, what I am really trying to say is this:   static analysis (and  
also dynamic analysis) should be
implemented by folks that are very familiar with optimization theory,  
since avoiding false-positives
is very often necessarily going to rely on some form of iterative- 
data-flow analysis, which while
fairly simple conceptually, isn't typically understood well enough by  
pure "front-end" only folks
that are traditionally given the task of implementing these  
analyses.  --- well, perhaps I am over-
analyzing the situation a bit,  but I do think things could stand  
some improvement anyway.


just my $0.02, your milage may vary...


-Peter Lawrence.




On May 13, 2011, at 3:36 AM, cfe-dev-request at cs.uiuc.edu wrote:

> I created a bug report some time ago http://llvm.org/bugs/ 
> show_bug.cgi?id=8914 I realize that fixing this is non-trivial, but  
> it would be nice if the analyzer could at least handle the following:
>
> if foo():
> 	x = 5
> else:
> 	exit()
> bar(x)
>
> without complaining that x might be uninitialized.
>
>
> Kind regards,
> Erik

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20110516/a4bb3111/attachment.html>


More information about the cfe-dev mailing list