[PATCH] D26442: [analyzer] Fix crash on getSVal: handle case of CompoundVal

Artem Dergachev via cfe-commits cfe-commits at lists.llvm.org
Fri Nov 11 10:14:27 PST 2016


NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

I think this patch is good to land, but if you have time i'd suggest to investigate this a little bit deeper in order to squash even more bugs.

My concern is that we've never implemented reading from a default-bound compound value, because we thought it never happens because we always bind it directly field-by-field instead.

So, since you've found a place where we default-bind a compound value as a whole, it might be great to investigate which consequences does this behavior have. For instance, can we load a field value from a default-bound compound value? If not, it'd be a direct benefit to unpack the value properly upon binding. Eg., an `ExprInspection`-based test of the form "`C c = { 42 }; clang_analyzer_eval(c.x == 42);`", where `C` is a type that triggers default-binding the initializer list (a union?), might expose the problem.


Repository:
  rL LLVM

https://reviews.llvm.org/D26442





More information about the cfe-commits mailing list