This is an archive of the discontinued LLVM Phabricator instance.

[analyzer] Assert that nonloc::SymbolVal always wraps a non-Loc-type symbol.
ClosedPublic

Authored by NoQ on Jun 14 2018, 8:10 PM.

Details

Summary

nonloc::SymbolVal that contains a pointer-type or reference-type symbol is ill-formed; our code isn't prepared to work with such values. The canonical way of representing symbolic pointers is loc::MemRegionVal that wraps a SymbolicRegion for the respective symbol. For representing results of casting pointers into integers we have nonloc::LocAsInteger.

This is the one assertion that i regret accidentally omitting in D26837, because it's very fundamental.

The assertion indeed mostly holds on our tests; i found one violation (in my own code), but the ill-formed SVal was only used in intermediate computations and was never put into the program state.

https://bugs.llvm.org/show_bug.cgi?id=37802 contains another example of an ill-formed SVal of this kind, which causes a crash. This patch doesn't address that crash yet.

Diff Detail

Repository
rC Clang

Event Timeline

NoQ created this revision.Jun 14 2018, 8:10 PM
george.karpenkov accepted this revision.Jun 15 2018, 9:32 AM
george.karpenkov added inline comments.
lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
1241

So what is the difference here? That SVB.makeSymbolVal is not always a nonloc?

This revision is now accepted and ready to land.Jun 15 2018, 9:32 AM
NoQ added inline comments.Jun 25 2018, 4:50 PM
lib/StaticAnalyzer/Core/SimpleSValBuilder.cpp
1241

That's right; it will be a symbolic region instead.

It won't affect the result of the calculation though (hopefully) (in the current implementation).

1241

I mean, it will *sometimes* be a symbolic region (when the symbol is of pointer type).

This revision was automatically updated to reflect the committed changes.