[cfe-dev] Checking Model Used by 'ArrayBoundV2'

Ted Kremenek kremenek at apple.com
Mon Dec 5 16:36:16 PST 2011


On Dec 3, 2011, at 10:48 PM, Anna Zaks wrote:

>> E.g. I would expect that even in the purely intraprocedural case it
>> could catch something like this:
>> 
>> int *foo, *bar;
>> int baz = something;
>> 
>> foo = (int*) malloc(CONSTANT * sizeof(int));
>> bar = (foo + CONSTANT + 1);
>> *bar = baz;
>> 
>> , which the present implementation of 'ArrayBoundV2' does not catch.
> 
> This example is not handled because the checker does not reason about malloc. Note, the analyzer CAN find the bug in the following example:
> 
> void m() {
>    int foo[3];
>    int *bar;
>    bar = (foo + 3 + 1);
>    *bar = 3;
> }

The way I'd like to see this generally approached is that ArrayBoundV2 could consult some API to check the "known bound" for a region.  We have a mechanism, known as "extents".  Specific checkers could register their knowledge of extents (e.g., the Malloc checker could register an extent for malloc'ed memory) and ArrayBoundCheckerV2 just cues off that extent information.

I'm interested in a general, scalable solution for adding such information.  In the short term, that could be added to ArrayBoundCheckerV2 as a post-visit on CallExprs.  This would leave the current bounds checking logic to just consult the generic extent information in the ProgramState.

More generally, I'd like any checker be able to register information about extents, and then have the ArrayBoundCheckerV2 automatically get smarter by leveraging such domain-specific information.  Further, once IPA comes available, we may be able to infer this extent information by other means.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20111205/477b4443/attachment.html>


More information about the cfe-dev mailing list