This patch aims to fix derefencing, which has been debated for months now.
Instead of working with SVals, the function now relies on TypedValueRegion.
Since this has been discussed since the inception of the checker, I'd very much prefer finding a permanent solution for this before moving forward.
@Szelethus @NoQ @xazax.hun I ran into an issue related to this line.
Consider this test case:
At this point, with the example above, the store looks like this:
which means the values are the following:
when State->getSVal(R, DynT) is called, eventually RegionStoreManager::getBinding() will also be invoked, where because R is an ElementRegion we reach these lines:
What happens here is that we call getBindingForElement(B, ER) and whatever value it returns, we cast to T, which is int * in this example. The type of the element inside the ER however is an int, so the following lookup will be performed:
Since extents are ignored by default, the returned value will be &Element{temp_object{CyclicPointerTest1, S915}.ptr,0 S64b,int}}, which is indeed a pointer, however I'm not sure that the lookup here is actually correct.
As far as I understand, we want to lookup an int element based on it's region and we receive a pointer value. Is it because I misunderstand something, or it's an actual issue that is hid by how region store works right now?