[cfe-commits] r86538 - in /cfe/trunk: lib/Analysis/CMakeLists.txt lib/Analysis/GRExprEngineInternalChecks.cpp lib/Analysis/GRExprEngineInternalChecks.h lib/Analysis/PointerArithChecker.cpp test/Analysis/ptr-arith.c

Ted Kremenek kremenek at apple.com
Mon Nov 9 18:08:21 PST 2009


On Nov 9, 2009, at 6:02 PM, Zhongxing Xu wrote:

> 2009/11/10 Ted Kremenek <kremenek at apple.com>:
>> Hi Zhongxing,
>>
>> I'm not convinced this is a good check, as there are a bunch of  
>> valid cases
>> where you would do this.
>>
>> First, I think this has the potential to flag a bunch of false  
>> positives on
>> OO code, like Gtk+.  One thing I've noticed is that some C code  
>> tries to
>> compute the start of the object from the address of a field (using
>> offsetof).  That seems reasonable to me, and appears frequently in  
>> certain
>> kinds of code bases.
>>
>> Second, consider C++ iterators.  For example, in our own code base  
>> we might
>> write:
>>
>>  SourceRange R = ...
>>  foo(&R, &R+1);
>>
>> where the '&R+1' represents the "end" iterator.  This is a case  
>> where a
>> variable is treated as an array of size 1.  We'd flag a warning  
>> every time
>> this idiom appears.  That doesn't seem useful.
>
> Sounds reasonable. If this checker cause many false positives I'd like
> to remove it.

Okay.  Let's grind it through real code and see what we get.

>
>>
>> It seems to me that buffer overflow checking, where an actual load/ 
>> store is
>> done on a invalid offset, will catch more real issues.  Are there  
>> cases that
>> we will miss with buffer overflow checking that this one will cover?
>
> We don't have a suitable scheme to represent the location of
>
> int x;
> &x + 1;
>
> Shall we create an element region with offset 1 and super region of a
> scalar type?

Yeah, it seems like ElementRegion(VarRegion(x), 1) would represent  
that location just fine, even that loading/storing from that address  
is bad.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20091109/f642eea3/attachment.html>


More information about the cfe-commits mailing list