[cfe-commits] r66892 - in /cfe/trunk: include/clang/Analysis/PathSensitive/BasicValueFactory.h lib/Analysis/RegionStore.cpp test/Analysis/ptr-arith.c

Ted Kremenek kremenek at apple.com
Fri Mar 13 10:08:51 PDT 2009

On Mar 13, 2009, at 8:52 AM, Douglas Gregor wrote:

> On Mar 13, 2009, at 8:35 AM, Ted Kremenek wrote:
>> Author: kremenek
>> Date: Fri Mar 13 10:35:24 2009
>> New Revision: 66892
>> URL: http://llvm.org/viewvc/llvm-project?rev=66892&view=rev
>> Log:
>> Fix failure reported by Sebastian of test/Analysis/ptr-arith.c when  
>> the target
>> is 64-bit. I used his suggestion of doing a direct bitwidth/ 
>> signedness
>> conversion of the 'offset' instead of just changing the sign. For  
>> more
>> information, see:
> This kind of APSInt bitwidth/signedness problem has bitten us  
> several times in several places, which makes me think that there are  
> more of such problems lurking. Perhaps we should put a layer of  
> abstraction over APSInt that automatically widens or sign-corrects  
> when performing the various arithmetic and comparison operations?

I'm actually not interest in such automatic conversions, at least as  
far as the analyzer is concerned.  In the analyzer my hope is to model  
(over time) the precise semantics with regards to sign-extensions,  
truncations, etc., that can occur in different places.  This is  
important for integer overflow checking and modeling the correct  
semantics of the program.  Perhaps an automatic conversion is  
appropriate in this instance, but in my mind this patch is just a hack  
that identifies one place where we need to think more deeply about the  
precise semantics of the underlying program operation.

Another reason I want to explicitly model places for sign-extensions,  
truncations, etc., in the analyzer is that APSInt may likely be only  
one of a couple numeric representations that will be in the analyzer.   
For example, this test case tests the analyzer's reasoning about  
pointer arithmetic, and hypothetically the offset could be a symbolic  
value instead of a specific integer constant.  Knowing when and where  
the integer conversions need to take place is something the analyzer  
simply has to model.

More information about the cfe-commits mailing list