[clang] [llvm] Adapted MemRegion::getDescriptiveName to handle ElementRegions (PR #85104)

via llvm-commits llvm-commits at lists.llvm.org
Fri Mar 15 01:42:02 PDT 2024


T-Gruber wrote:

> In addition to the above-mentioned issues there is also a conceptual problem with using `getOriginRegion()` to describe a symbol: it names the region where the symbol _originated_ (if it originated as the unknown initial value of a symbol), which is not necessarily the region where the symbol is stored _now_.
> 
> For example consider the (somewhat contrived) code
> 
> ```
> int matrix[10][10];
> int func(int x, int y) {
>   int tmp = x;
>   x = y;
>   y = tmp;
>   return matrix[x][-999]; 
> }
> ```
> 
> Here the checker alpha.security.ArrayBoundV2 (which uses `getDescriptiveName`) would report that
> 
> ```
> Access of 'matrix[y]' at negative byte offset
> ```
> 
> because the symbolic value of the index _originated from_ the parameter `y` (i.e. the symbol is identified as "this is the initial value of `y`).

Yes, thats right. But the previous implementation ended up in an endless recursion if the index is not of type ConcreteInt. Therefore, the proposed version is a significant improvement (at least for my use cases).

https://github.com/llvm/llvm-project/pull/85104


More information about the llvm-commits mailing list