[SCA] Should the super region of the ElementRegion always be typed?

Clang Frontend
1

Consider this code:

void foo(int *p) {
p[0] = 1;
}

Currently we evaluate p[0] to loc::SymbolVal. I want it to be
loc::MemRegionVal(ElementRegion(SymbolicRegion(SymbolRegionRValue(p)), 0)). But
ElementRegion assumes its super region be typed. Is this assumption too strong?

-Zhongxing Xu

2

Or, we could always know the RValue type of a symblic region?

3

How about we make SymbolicRegion subclass TypedRegion? Are there cases that we would have untyped SymbolicRegion?

4

I think we can go ahead make SymbolicRegions typed until we have a reason for them not to be. FWIW, symbols themselves are typed, so it makes sense for their associated regions to also be typed.

I think for "untyped" symbolic regions the RValueType can be "void". AnonTypedRegions can then help with layering the appropriate type information, e.g. in the following case:

void bar(void *p) {
   ((char*) p)[0] = 1;
}

Here ((char*) p)[0] would evaluate to:

loc::MemRegionVal(ElementRegion(AnonTypedRegion(char, SymbolicRegion(SymbolRegionRValue(p))), 0))

5

Consider this code:

void foo(int *p) {
p[0] = 1;
}

Currently we evaluate p[0] to loc::SymbolVal. I want it to be
loc::MemRegionVal(ElementRegion(SymbolicRegion(SymbolRegionRValue(p)), 0)). But
ElementRegion assumes its super region be typed. Is this assumption too strong?

Or, we could always know the RValue type of a symblic region?

How about we make SymbolicRegion subclass TypedRegion?

Sounds great to me.

Are there cases that we would have untyped SymbolicRegion?

An “untyped” region could potentially just have type “void” or some similar marker.

6

If we do this, it would lead to a series of changes:

To get the rvalue type of the region, we need to get the type of the symbol. SymbolManager is required to do this: get the SymbolData by SymbolRef. The interface need to be changed:

TypedRegion::getRValueType(ASTContext&) → TypedRegion::getRValueType(ASTContext&, SymbolManager&)

But this is not desired for other typed regions.

Or, we can make getRValueType a method of MemRegionManager. But that would need the access to MemRegionManager everywhere when we need the type of the region.

7

A third option is to embed a reference to the SymbolManager in the SymbolicRegion. One would need to pass it to MemRegionManager::getSymbolicRegion(), but I see only two callsites for this function (one in BasicStore, the other in RegionStore), and in both places we should have access to the SymbolManager.

8

Yeah, this is better.