[cfe-dev] [analyzer] limits in reasoning about memory regions

[Alexander Droste via cfe-dev]

Thanks for the clarifications!

On 09.10.15 11:33, hao/NoQ via cfe-dev wrote:
> Hello, i'm not quite sure what you mean by setting a state for each
> element, but iterating over all possible sub-regions of a region is
> probably not what you really want.

I meant that I'm using the region as a key for objects in a map
registered with REGISTER_MAP_WITH_PROGRAMSTATE,
which are 'modified' by invoking:
State = State->set<CustomMap>(Region, ctor(.., enumState));.

> The program may allocate much more bytes than you want to iterate over
> during analysis (consider AddressSanitizer that allocates 16+TB of
> memory; you don't really want to set states for all possible elements
> of such array, the analyzer wouldn't be able to handle it; less
> corner-case examples are possible, of course).

I think for the context I analyze, it is highly unlikely that the arrays
have more than 100 elements. But this is a good catch I will keep in mind.

> Additionally, element regions with different element types are
> different regions, even if they represent the same memory segment,
> which allows for infinitely many different subregions of the same
> regions. If my understanding of your approach is correct, you should
> probably re-consider it and conduct your analysis over base regions
> instead.
>
> If you're trying to set bindings to all elements of a large array (eg.
> zero-initialize the output of calloc(), similarly to how MallocChecker
> does it), you're probably looking for the 'default binding' thing (see
> ProgramState::bindDefault()).

That sounds promising, I will give it a try.
Thanks again for your help!

> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>